RE: [boost] Formal Review: Pool - Major question

From: scleary_at_[hidden]
Date: 2000-12-05 09:43:35

> The main rationale for adding pool allocation is that it is "very 
> fast".

Actually, the original intention for pool<> was to have an object that, when
it goes out of scope, will call the destructors for any objects allocated
from it.  That is, a "poor man's garbage collector".

Other uses special to pool also exist; for example, using sized_pool, one
may skip deallocation overhead completely.

The idea for "pool" is to provide a set of interfaces that allow more
powerful and specific manipulation of memory, not to replace std::allocator.

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

There are two other allocator interfaces under development, too.  Allocator
overkill?  Maybe we should provide one "pool allocator interface" that is
based on Generative Programming...

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

On my platform (BCB5, Win32), the pool allocator is slightly *slower* with
this test.  This is due to a well-optimized STL (RogueWave's); each STL
container maintains a buffered free list that acts exactly like a pool.  So
using the pool allocator interfaces won't get you anything.  However, "It is
intended that a.allocate be an efficient means of allocating a single object
of type T, even when sizeof(T) is small.  That is, there is no need for a
container to maintain its own 'free list'." [20.1.5, note 214].  Thus, there
is no guarantee that other STL implementations will be so designed -- the
note quoted above seems to discourage it, so I suggest we keep the pool
allocator interface anyway.

Also, IMO, it makes new container design simpler.  I have a sll container
(who doesn't?) that uses its Allocator in the Standard-recommended naive
way; it would greatly benefit from pool.

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

I'll put out a simple test program soon.  I'd like to see the results of
other platforms as well.

        -Steve