Re: Emacs bzr memory footprint

[Nix]

On 21 Oct 2011, Eli Zaretskii said:

>> Date: Fri, 21 Oct 2011 13:05:42 +0100
>> What, even if what's happening is massive allocation of conses followed
>> by allocation of longer-lived stuff followed by freeing of those conses?
>
> I'm really not an expert on this, but I think the answer is YES.  At
> least the GNU/Linux build does not use the gmalloc.c and ralloc.c
> modules, AFAIK because the native malloc on GNU/Linux includes the
> same or superior functionality.

Unfortunately it won't release memory back to the OS in the situation I
described. mmap() is expensive, so only large allocations (by
default >128Kb or >512Kb depending on glibc version and arch) get
mmap()ed. If you want to e.g. release all storage allocated for a buffer
*and its local variables* when that buffer is freed, you need a pool
allocator which can be told to allocate those local variables in a
buffer-specific mmap()ed pool... and glibc malloc has nothing like it.
(I'm thinking here of something like APR's pool allocators, though
obviously not actually those allocators. Something with a similar design
though.)

But this is all speculation. I'm running a debugging patch now courtesy
of Dimitry Antipov: we'll see what it turns up in the next few days (or
even possibly hours).

-- 
NULL && (void)