On Tue, Apr 3, 2012 at 12:35 AM, Martin Stjernholm, Roxen IS @ Pike developers forum <[email protected]> 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
