[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs bzr memory footprint

From: Nix
Subject: Re: Emacs bzr memory footprint
Date: Thu, 20 Oct 2011 14:35:31 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

On 14 Oct 2011, Sven Joachim said:

> On 2011-10-14 18:30 +0200, Ted Zlatanov wrote:
>> On Fri, 14 Oct 2011 17:49:16 +0200 Sven Joachim <address@hidden> wrote: 
>> SJ> I'm also experiencing memory leaks.  My current session is at 82M, with
>> SJ> the accumulated size of all buffers less than 1M; visiting files and
>> SJ> then deleting their buffers does not increase memory footprint, but Gnus
>> SJ> usage (visiting groups and articles) slowly but steadily does.
>> It's possible GnuTLS usage is part of the problem.  Do you use it?
> Yes.

So do I.

Here are two Emacses (quite old, I'm afraid, bzr 105407, must upgrade):

Oct07 832348 1127088
Oct07 226916 499588

The first Emacs does little but run Gnus and BBDB, including a bunch of
gnutls-accessed IMAP mailboxes at my employer's (Drew can probably tell
you *exactly* how that works, even if I use Gnus to access them and he
doesn't), but also including nnml and a bunch of ordinary nntp groups on
multiple servers. No images, no multicharset stuff except whatever I run
across on emacs-devel :)

The second Emacs does no Gnus, but does *all* my software development,
my entire day job, and is much more heavily used, with far more active
buffers, including monsters like a TAGS file for the entire Linux
kernel. Yet its memory consumption is far lower. They have identical
configurations otherwise.

(garbage-collect) for the first:

((2118391 . 1218350) (83106 . 0) (80362 . 45727) 87827825 2736712 (7831 . 
20893) (94543 . 15062) (461420 . 158890))

For the second:

((1362224 . 894226) (51114 . 79) (17329 . 6290) 9620209 952486 (747 . 4077) 
(84546 . 5233) (336029 . 181268))

Gnus is clearly driving Emacs much harder than mere cc-mode ever does.
I'm particularly stunned by the number of string-chars in use. It must
have some huge variables defined, probably holding overview data or
something... I'm not sure how large some of those things are: if they're
large structures this might explain most or all of the memory

reply via email to

[Prev in Thread] Current Thread [Next in Thread]