Subject: Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2012-07-18 17:25:32
>> I evaluated Boost.Pool some (long) time ago as a way to optimize performance
>> for a few of my applications but it appeared even slower than the system
>> allocator, let alone specialized solutions. Frankly, I don't see much point in
>> pooling raw memory nowdays, except to achieve more control on when the memory
>> is released. A per-container memory pool with no locking at all might also
>> squeeze some performance, but considering per-thread memory pools in the
>> system allocator this gain remains to be proved. A portable aligned memory
>> allocator perhaps? Useful, but that's an item for Boost.Allocator and not
> As for Pooling, there is still some use cases on embedded systems where
> you are required to pool some Mb at the beginning of the applications
> then you want to go through normal allocator/container design to access it.
> Gb of RAM on COTS computer are not the only use case around ;)
I am one of those embedded systems developers who pools small
chunks for one-shot allocation, for example.
I just need how to find the time to figure out how to use pool better.
Best regards, Chris.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk