Formal Review: Pool - Major question

From: Beman Dawes (beman_at_[hidden])
Date: 2000-12-05 07:34:10

I believe the acceptance of pool library should be deferred until timings 
are provided to justify the complexity of the library.

The main rationale for adding pool allocation is that it is "very 
fast".  Yet without timings, how are we to know if this is correct?

Science without measurement isn't science, it's witchcraft.

Let's look at pool_allocator and fast_pool_allocator, for 
example.  Including std::allocator, do we really need three 
allocators?  Only if the proposed new allocators are significantly faster 
that std::allocator or each other in real applications.

For example, inserting and then deleting a million random numbers into a 
std::set is a the simple test I would consider an approximation of a real 
application.  If, across many platforms, this test ran 10% faster on 
average using the pool allocators, I wouldn't consider that enough faster 
to justify including these interfaces.  On the other hand, if this test 
often ran 50% faster, that would be enough for me.  Others would have their 
own opinions as to when the performance gain is great enough to justify the 
added complexity and resulting user confusion.

So I'd like to see Steve or others provide a simple test program that for 
each component in the pool library compares the speed of the pool library 
to the alternatives (new/delete or std::allocator as appropriate).  I'd 
like to see boost members run the timings on their platforms and report 
back the results.  Then we will have a factual basis for a claim that pool 
allocation is "very fast" and so well worth adding to boost.

--Beman