[Top][All Lists]

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

Re: Proposal: block-based vector allocator

From: Stefan Monnier
Subject: Re: Proposal: block-based vector allocator
Date: Thu, 08 Dec 2011 08:52:57 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.91 (gnu/linux)

>> 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.


>> 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.

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.


reply via email to

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