[Top][All Lists]

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

Re: Emacs bzr memory footprint

From: Nix
Subject: Re: Emacs bzr memory footprint
Date: Fri, 21 Oct 2011 20:12:24 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.90 (gnu/linux)

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!

reply via email to

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