Re: Proposal: block-based vector allocator

[Dmitry Antipov]

On 12/06/2011 11:39 PM, Stefan Monnier wrote:

> Is that more or less what you had done?  It's a very standard and
> popular malloc algorithm, so I'm surprised you say it didn't work well.

The point is that it makes no sense to have 'standard malloc algorithm'
for vector allocation on top of another 'standard malloc algorithm' used
by C library malloc. To get an advantage over plain malloc()/free() pair,
we should have something specially tailored for our needs instead of
duplicating library functionality at the higher levels. Any good
allocator should be a well-designed balance between complexity, speed,
code size, fragmentation, etc., but I'm trying to target smallest possible
fragmentation and best possible heap utilization with smallest possible
waste. This is especially important because our heap is very unlikely to
shrink and tends to be very fragmented.

> So we should have a fair bit of wiggle room here.  Especially since I'm
> not specifically interested in reducing memory use as much as getting
> rid of the O(log n) overhead and generally making smallish
> "defstruct-style" vectors more efficient.

This approach looks pretty strange for anyone who looks through this list's
archives: "my Emacs is too slow" noise is quite rare, but "my Emacs is
too fat" topics are raised over and over again.

I believe Emacs is fast enough to be a good editor on any reasonable hardware.
Even for an instance bloated with a few hundreds of buffers, I never seen
a GC longer than 0.1s, which is faster than a keystroke. So, eliminating
an logarithmic overhead in one of internal subsystems is insignificant. But,
when an editor with 0 (zero) open files consumes more memory than a web
browser with 10 open tabs, it's just a shame.

Dmitry