[Top][All Lists]

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

Re: Emacs bzr memory footprint

From: Eli Zaretskii
Subject: Re: Emacs bzr memory footprint
Date: Fri, 21 Oct 2011 10:19:18 +0200

> From: Nix <address@hidden>
> Emacs: well, why *shouldn't* you pay property taxes on your editor?
> Date: Fri, 21 Oct 2011 01:19:53 +0100
> Cc: address@hidden
> On second thought, IIRC Gnus allocates some very large lists as part of
> its overview management or something: perhaps this is serving to spam
> the arena with a huge number of (individually small, thus not
> mmap()-allocated) atoms which, when they get freed later, produce a very
> sparsely-filled, severely-fragmented heap? If so, perhaps Emacs would
> benefit from a simple pool allocator accessed via a new let/setq form or
> a new arg to create-buffer, so Gnus could arrange to stuff variables it
> knows will be huge, or buffer-local variables of buffers it thinks may
> have lots of huge buffer-local vars, into a newly-mmap()ed region?
> Unfortunately that means, sigh, using our own malloc() again, which is
> probably more painful than useful. I suspect actually proving my
> contention first would be a good idea. Not sure how to get the addresses
> of Lisp objects from a running Emacs though: gdb, presumably.

Do you see a similar growth of the footprint in Emacs 23.3?  None of
what you are describing seems to be specific to Emacs 24, so it would
be good to compare with the memory usage of Emacs 23.3.

As for memory fragmentation: this is on GNU/Linux, right?  If so, the
memory allocator used by Emacs should prevent any such fragmentation,
at least in the simple scenarios you described.  So I don't think
memory fragmentation can explain what you see.

reply via email to

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