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

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.