Le 18/07/2012 00:36, Andrey Semashev a écrit :
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.
A Boost.Allocator library with some useful yet non trivial to write allocators (we had to design an the aligned one and an aligned adaptor one for Boost.SIMD) could be pretty nice and fill a nice gap between std::allocator and the actual need of allocator in modern code. 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 ;)