Re: Emacs bzr memory footprint

[Eli Zaretskii]

> 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.