Re: Emacs bzr memory footprint

[Stefan Monnier]

>> If this output does not explain the process's size you're seeing, then
>> we have a leak in the C code somewhere.  If it does, then we have either
>> a leak in Elisp, or at least an excessive memory use by some package,
>> and hopefully we can at least figure out which category of object
>> is involved.
> ... or the same thing XEmacs apparently had, which was excessive memory
> consumption by one or more other still-unidentified C libraries.

Yes, that's what I meant by "in the C code somewhere".  Another thread
recently seemed to suggest that maybe the new C-level support for gnutls
may cause such problems.

> True! So it wouldn't be as hellish to write our own allocator as it
> would be for most projects, because we've done 90% of the work already
> (including the hard part: allocating things of variable size).

Actually, no, that doesn't include the hard part: we only do our own
allocation for fixed-size objects (cons, floats, markers&overlays,
symbols, string headers) plus relocatable variable size objects (string
text).  For the non-relocatable, non-fixed size objects (i.e. vectors)
we defer to malloc.

> Yeah. As an aside: most of the inside of Emacs is quite nice, but I am
> seriously unimpressed by overlay storage. Linear scans for
> 'overlays-at'? Ew. One of these years I might try to implement something
> better, like what XEmacs did for extents, so you can find extents over a
> given buffer position more efficiently... (not because this is visibly a
> problem in profiles that I've seen, merely because the inefficiency
> offends me :) )

Yes, overlays (and to some extent markers) are in serious needs of
a redesign.  We get bitten by this performance problem, which is why
a lot of code goes through a fair bit of trouble to avoid overlays and
use text-properties instead (and the code that doesn't bother doing
that is usually only usable on small buffers).


        Stefan