Re: Proposal: block-based vector allocator

[Stefan Monnier]

>> I'm not convinced your result is because your code does better than
>> malloc.  Instead I expect it's because it avoids the mem_node overhead.
>> Recompiling and trying again without conservative stack scanning should
>> factor out this effect.

> Without conservative stack scanning, it works at least not worse
> (I believe we should ignore the differences less than, say, 0.5%).

Sounds about right (performance of vector allocation, both in terms of
memory and CPU use, should be lost in the noise unless the allocator
really suffers from a serious problem, as is the case with the current
allocator because of the mem_node allocated alongside).

> But, as I have said, there are further improvements possible.

I think the improvements should focus on simplicity since I doubt we can
get measurably much better.

>> You can't do compaction without changing the Lisp_Vector's layout
>> (adding an indirection, as is done for Lisp_Strings).
> I know, and I'm just saying that my proposal contains nothing which
> makes compaction impossible or too tricky.

OK.

>> I thought we agreed that GC performance is not a concern here.
>> Of course, every change to the layout can impact the performance of the
>> GC.  Have you measured the impact of your code on GC performance?
> Not yet. But will do it, of course.

I wouldn't bother.

BTW:
I'm still curious why you have a "order608" for 4KB blocks, since
dividing the 4KB block into 608 would leave you with a lot of padding at
the end and reducing the number of distinct "orders" should
reduce fragmentation.


        Stefan