Re: Proposal: block-based vector allocator

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> How much did it help?
> Not too much because it makes no sense without block-based vector

Your test with the *compilation* seems to indicate otherwise, or am
I missing something?

>> And you said that using the non-conservative stack scanning resulted in
>> similar results, so all that extra memory is occupied by mem_nodes (or
>> fragments that used to hole mem_nodes ;-).
> Yes, one mem_node per each vector results in substantial overhead and
> fragmentation. _Any_ block-based vector allocator should reduce the number
> of mem_nodes, so saving space - but rounding allocator will consume some

Exactly: no need to work hard.

> of this space back for it's own internal fragmentation.  That's why
> I proposed the scheme with tightest possible fit instead of 'standard
> malloc algorithm'.

The apparently tightest fit is not necessarily tighter: what happens if
you use an "order624" to allocate a 600B object, then use the remaining
24B for another object, and then free the 600B object?

I also really want to know the answer to this question (third try):
Why have different classes for 632B and 600B sizes?  You can't fit more
than 6 vectors of either size in a 4KB block, so you might as well
divide your "order600" block into 6 chunks of 680B (plus 16B of padding)
rather than 6 chunks of 600B plus an unused 496B of padding.


        Stefan