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

From: Darren Cook (darren_at_[hidden])
Date: 2003-05-07 18:28:14

>>>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.

Well it was a real-world example and I only applied it to one of the 
classes. 2-3% speed boost for only three extra lines of code (header 
include, new, delete) is worth having.

> 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.

Anywhere in Boost is fine by me; currently it is in boost::detail and not in 
the documentation.

However if I went looking for something to speed up memory allocation, 
"pool" is what I'd be looking for, so it seems the logical location.

 > Quick_allocator is mainly an optional shared_ptr optimization.
> ...
> ... quick_allocator is really not intended to be used with
> objects that are 512 bytes in size. :-)

It has applications beyond the original design purpose.

>>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.

OK. How about a template parameter to specify page size? We could use the 
platform and the class size to guess a good default.

Where I'm going with this is if I know from profiling that typically my 
program will peak at using 1000 objects, then I can simply change the page 
size to be that big (maybe rounded up to a certain multiple - does incorrect 
page size matter much if there is just one allocation?). Just as I would use 
reserve() with vector, and just like that I know it can expand if usage is 
non-typical.

Darren

P.S. I'm willing to help out, including writing a tutorial.