Re: Proposal: block-based vector allocator

[Stefan Monnier]

>> BTW, if we change the vector allocation so it only uses vector-blocks
>> for vectors smaller than "vector-block-size / 2", as I think we should,
> Why?

I explained this earlier: using a vector-block for largish vectors is
not efficient (because the overhead of the vector-block is not shared
among enough vectors).
E.g. for a vector of size VECTOR_BLOCK_BYTES, using the vector-block
code is a complete waste .

> Whatever this limit's value, it's possible to construct an allocation
> pattern which will be a worst-case for this allocator, and I don't see
> why one specially designed worst-case is more probabilistic than another.

For the case of a vector of size VECTOR_BLOCK_BYTES, allocating in
a vector block will always be a bad idea, no matter the scenario.
Now obviously, this is not true of all vector sizes, and I don't know
where's the threshold where we should switch from one to the other, but
vector-block-size / 2 sounds like a safe choice (even if the threshold
is not quite there, there's probably not much to gain from being
closer).

>> I'm not saying the code is wrong.  I'm saying that its correctness
>> should be made more explicit by using a different MEM_TYPE for
>> vector blocks.  This way the correctness argument is trivial rather than
>> relying on some reasoning about which kind of vector allocation
>> is used in which circumstance.
> Yet another mem_type duplicates live_vector_p,

I don't see why that should be the case.


        Stefan