Robin wrote:
My understanding is that the pool allocator is made for repeated allocation and deallocation of same-sized blocks, in which case the result makes sense. I think it's more intended for use with node-based containers such as list and map.
I tried with list, the std::allocator is still faster
typedef list <A, boost::pool_allocator <list <A>::value_type > > ListA; ListA listA;
then
listA.push_back (A ()); listA.pop_front ();
Or with boost::shared_ptr as I need to keep a polymorphic pointer.
typedef list < boost::shared_ptr <A>, boost::pool_allocator <A> > ListA; ListA listA;
then
listA.push_back (boost::shared_ptr <A> (new A ())); listA.pop_front ();
I can't get map to compile,
typedef map <string, A, boost::pool_allocator <std::map <string,A>::value_type >
MapA; MapA mapA;
mapA.insert (make_pair ("test",A ()));
VC8 balks at this line at the xutility comparision predicate header. It compiles fine with the std allocator.
Am I using pool incorrectly?
Robin
On 30/12/2007, Robin <al@cyberversion.com> wrote:
I've been testing out boost pool allocator, and my results shows it's slower than the STL allocator. I'm using VSNet 2005 SP1. See test code below.
My understanding is that the pool allocator is made for repeated allocation and deallocation of same-sized blocks, in which case the result makes sense. I think it's more intended for use with node-based containers such as list and map.
From the docs: http://www.boost.org/libs/pool/doc/interfaces/pool_alloc.html The Fast Pool Allocator ... If you are seriously concerned about performance, use fast_pool_allocator when dealing with containers such as std::list, and use pool_allocator when dealing with containers such as std::vector. Jeff Flinn