Boost logo

Boost :

Subject: Re: [boost] pool allocation
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2009-09-24 18:02:46


On Thu, Sep 24, 2009 at 6:28 PM, Stefan Strasser <strasser_at_[hidden]> wrote:
> Am Thursday 24 September 2009 23:30:18 schrieb OvermindDL1:
>> On Tue, Sep 22, 2009 at 7:17 PM, Emil Dotchevski
>>
>> <emildotchevski_at_[hidden]> wrote:
>> > Have you considered/evaluated dlmalloc?
>>
>> Or tcmalloc?  (Google's memory pool/alloctor, amazing time efficiency)
>
> external library suggestions are appreciated but besides the point, since this
> code is part of a boost library proposal.
> don't you think Boost.Pool is missing something here? something that's not
> very hard to write, since there is Boost.Intrusive, so you can implement
> allocation algorithms quite easily.
> even pools that support allocation of arbitrary sized objects using an
> intrusive set and an allocation algorithm like the ones deployed by
> Boost.Interprocess here:
> http://www.boost.org/doc/libs/1_35_0/doc/html/interprocess/allocators_containers.html#interprocess.allocators_containers.memory_algorithms.rbtree_best_fit
>
> I've used something similar for a disk space allocator:
>
> typedef set_base_hook<tag<by_size_tag> > by_size_hook;
> typedef set_base_hook<tag<by_offset_tag> > by_offset_hook;
> struct free_block : by_size_hook,by_offset_hook
> ...
> intrusive::multiset<free_block,base_hook<by_size_hook>...
> intrusive::set<free_block,base_hook<by_offset_hook>...
>
> allocation and deallocation of arbitrary sized blocks in O(log N), with block
> merging and block splitting. in a few hundred lines of code.

Actually something like Google's pool allocator is quite simple, I
actually created one very much like it years ago, would be quite
interesting to create another Boost.Pool that gave similar
functionality to it, would round out the Boost.Pool's quite well. :)

But yea, Boost.Pool itself does need some enhancements, needed them
for a long time, that is why I wrote my own a long time ago, ran much
faster.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk