[boost] Re: Yet Another Pointer Policy Proposal... Fast One

From: scleary_at_[hidden]
Date: 2002-07-28 20:21:57

> P.S.  One could argue that boost::pool exists to provide a faster
> allocator than say, malloc.  Or, one could argue that it exists to use
> memory more efficiently. ;)

Actually, Boost.Pool is best at handling "unusual" memory requirements --
the canonical example being having to allocate some large number of small
objects during the course of an algorithm, and then dropping them all at
once (maybe without running destructors) -- using pool allows you to do this
type of operation without having to free the object pointers.

It does provide speed increases in some situations as a side effect, but in
no way can it be a generic replacement for malloc.

This is not to say that Boost will never accept a library whose sole purpose
is efficiency, but there must be reasonable limits.  I once began re-writing
every container in the STL with what I called "relaxed assignable"
requirements -- i.e., copy construction/assignment that did not assume that
the two copies were equal.  This can be done, but the complexity involved
outweighed the benefit.  It's just plain easier to use
std::vector<boost::shared_ptr<T> >, and just live with the slight amount of
overhead.

I read a compelling argument one time against premature optimization; I
forget the source.  But the author had brought up one example where a
programmer went to great lengths to do a certain optimization -- but the
amount of time that the programmer spent on it would never equal the amount
of time the optimization saved, even if used by tens of thousands of
customers over a hundred years...

This is also one reason why obscure syntax is greatly frowned upon; the
harder the syntax is to learn/remember, the steeper the learning curve --
for you, and others who review your code, and others who maintain your code,
and yourself coming back to your own code years down the road.  Good
programmer time is a very valuable commodity, and with the speeds of
computers continuing to rise, saving a few machine cycles just isn't worth
it.

Now, allow me to just say a couple words from the other side of the fence,
because I *am* a bit of an "efficiency freak" -- I hate doing anything
inefficiently, and there is a part of me that winces every time I write
std::vector<shared_ptr<T> > when I know that no shared_ptr<T>'s will be held
outside that vector...  Each time I have to remember the argument above, and
make myself admit that fixing it is not a good investment.

I see "Boost" as boosting programmer productivity, or sometimes as boosting
the expressive power of C++ (regular expressions, closures, functional
programming...).  And, naturally, each library should be as efficient as
possible; but not to the point of restricting programmer productivity or
expressive power.

Of course, all of the above is IMO. ;)

        -Steve (author/maintainer of Boost.Pool)