Re: Emacs bzr memory footprint

[Nix <nix@esperi.org.uk>]

On 21 Oct 2011, Stefan Monnier spake thusly:
>> 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.

Oh heck. I assumed that were were allocating the strings themselves, not
just their headers, and didn't check the source code. Mea culpa.

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

Oh good. On my huge todo list it goes then!