$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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.