RE: [boost] Pool Review: Documentation

From: scleary_at_[hidden]
Date: 2000-12-05 08:06:39

> > > 1) User examples are needed.  Please, some usage examples
> >
> > This is on the TODO list.
> 
> Ok, hopefully sooner rather than later....
> 
> > > 2) Ok, so what's the advantage?  As a user I want to seem some example
> > I assumed that users of this library would be at least aware of how a
pool
> > is supposed to work, and thus be aware of the advantages and>
disadvantages.
> 
> Most developers won't be users unless you spell some of this out.

I'll add an "introduction" page -- covering the "what, why, when, and how"
of pools.

> > Faster performance and (possibly) reduced memory usage are the
advantages.
> 
> Hmmm...I guess I'm expecting higher memory usage typically with a fixed
> pool?

Maybe.  If you have small object sizes, you can cut in underneath the memory
overhead of most system-supplied allocators.  This is because these system
allocators have to store the size of the block along with the block, so for,
say, int-sized objects, you get 50% wasted memory.  So once you allocate
FirstArraySize/2 chunks from a pool, your memory waste at worst-case is the
same as the system memory waste, until you start deallocating.

> > The disadvantages are more complicated code and loss of generality.
> I'm not sure what you mean by "generality".  In many
> cases the user code isn't really different....

Meaning that trying to write a general-purpose memory allocator from pools
would be wrong.  That's not what they should be used for.

> > *not* only advantages; I don't want users plugging in pool to their code
> > everywhere thinking that it will magically make their program run 8x
> > faster...
> 
> That's the point isn't it?  It really is magic!

It should be easy to use, but IMO memory allocation is not a huge overhead
in real-world programs.  In my mind, pools should be used more for
optimization -- and never optimize until you know you should.  Though, if we
make it easy enough to use (thinking of the B&N base class here), it may
find use as a general policy: something like "always make small classes
derive from pool_base".

> I suggest you report "the results" for one
> combination, provide the source for the tests and let the users run the
> benchmarks on their own platform/compiler.

This sounds good.  I'll add some timing results.

> http://www.boost.org/libs/smart_ptr/smarttests.htm
> The summary provides a one paragraph description of some of the
performance
> factors to consider in smart pointer usage.  This doesn't eliminate the
need
> for me to go run my own tests, but it helps me focus my time. 

Yes, I remember some time ago when this was being done.  The "special
counted" smart_ptr essentially uses a pool.  I see no problem testing out
different ideas like this for pool, as people bring them up.

> Well, if the one I upload is correct, it's yours for free.  If you want to
> link it to files I can send you some html that should do the trick...

Thanks!  Yes, I'll take the html, too -- never done imagemaps :)

        -Steve