Subject: Re: [boost] [pool] Calling all library designers: The future of Boost.Pool???
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-07-17 18:36:02
On Tuesday 17 July 2012 19:35:40 John Maddock wrote:
> Hopefully others will chime in here with their requirements as well.
I think it's important to understand the aim and scope of the library first.
With current system allocators (such as tcmalloc, which uses per-thread pools
internally, AFAIK), is there a real use for explicit memory pools? Why STL
components such as vector and string (which typically don't release memory
until destroyed) and an efficient system allocator are not enough? I can
hardly imagine a use-case for a pool allocator to be used with a container.
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
My point is that the scope of the library is very small and the benefits it
may provide are not evident. The only real application of this library I'm
interested in is a container-local memory pool with no locking at all to
achieve better performance. Maybe others can provide real use cases for memory
pooling, and after that we can compile requirements.
There is also an option to repurpose the library. Pooling raw memory may not
be that needed today but pooling constructed objects is another story. More
than once I had cases when constructing an object, including collateral
resource allocation and initialization, is a costly operation and it is only
natural to arrange a pool of such objects. While in the pool, the objects are
not destroyed but merely "cleaned". An object can be retrieved and returned to
pool multiple times, which saves the costly initialization. I could use a
framework for building such pools. I think this is the most productive way of
development of the library.