Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???

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

<snip>

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