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.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk