Re: [boost] Re: boost::pool speed tests

From: Peter Dimov (pdimov_at_[hidden])
Date: 2003-05-07 08:17:30

Darren Cook wrote:
>>> Is there interest in a "SimplePool" class that is quicker and less
>>> flexible?
>>
>> You might look at boost/detail/quick_allocator.hpp
>
> Thanks. Once I rememebered to disable threads it gave the quickest
> results (included below for comparison). Are there plans to move this
> into the pool library?

Judging by the results below, your new/delete allocator is already pooling,
so you shouldn't bother. :-) Quick_allocator is only worth using on
platforms where it gives a factor of 2 improvement, sometimes more.

Quick_allocator doesn't really fit the Boost.Pool philosophy AFAIK since it
never releases memory; I think that the intent of Boost.Pool is to support
"region"-based memory management, i.e. efficiently deallocate a bunch of
objects in a single call. Quick_allocator is mainly an optional shared_ptr
optimization.

> I found one bug: if BOOST_QA_PAGE_SIZE is not defined, and the class
> size is bigger than 512 bytes then items_per_page comes to zero:
>      enum { items_per_page = 512 / size };
>
> Is this a job for the Boost concept check library? E.g. assert that
> items_per_page is at least 2.

Yes, that's correct, quick_allocator is really not intended to be used with
objects that are 512 bytes in size. :-)

> I think it would be nice if items_per_page were a template parameter,
> so I can specify it for each class.

Setting the correct page size is a black art, and items_per_page isn't the
most convenient way to do that (the "right" page size does not depend on the
size of the object). With an incorrect page size you can easily "achieve" a
factor of ten slowdown depending on the memory usage pattern.