On Tue, Apr 3, 2012 at 12:35 AM, Martin Stjernholm, Roxen IS @ Pike developers forum 10353@lyskom.lysator.liu.se wrote:
We pushed an experimental branch which uses a new block allocator we have been developing. /.../
I guess you already told us at the conference, but what was your motivation for creating it?
The linear lookup in the existing one...
Is std::allocator the same thing as the (g)libc malloc in your graphs?
No, std::allocator is a block allocator used by std::list, std::map and so on. Compared to glibc free/malloc, the std::allocator is quite fast.
I take it you already got it working as a replacement for the old BLOCK_ALLOC, including that quirky heap walker that the old one sports? Do you have any test where they are compared?
We used pike -x benchmark (because results there jitter a lot we averaged ~160 runs, which seems to give useful precision). I will dig up some results from that. However, -x benchmark may not at all be what should be used for meaningful comparison, but unfortunately we did not come up with anything better yet.
/.../ Currently, GJAlloc is requested as a bundle by the CritBit module, which uses its API directly.
Does it add any features?
Slight ones. For the CritBits, we need the allocator in the object storage (block allocators are used tree-locally). Other than that, GJAlloc supports ba_free_all() and ba_destroy().
All other modules use macro definitions which are compatible with the ones from block_allocator.h.
You mean the old block_alloc.h?
Yes, that we meant.
best,
tobi