Boost logo

Boost :

From: Mattias Flodin (flodin_at_[hidden])
Date: 2002-07-29 03:32:59


On Sun, Jul 28, 2002 at 07:19:48PM -0500, David B. Held wrote:
...
> Many libraries are a feature superset of existing code, perhaps; but
> their focus tends to be to provide correct, portable code rather than
> blazingly fast code (though unnecessarily slow code is obviously
> frowned upon).
...
> 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. ;)

I think an important distinction to make when discussing the need for
speed, is that of complexity differences versus execution-time
constants. As far as I know, all shared_ptr operations run or can be
made to run in O(1) complexity, and Phillipe's pointer may have a
smaller constant but it is still O(1).

With Boost.Pool, on the other hand, we get a lower _complexity_. Memory
allocation from a generalized heap is about O(log n), whereas allocation
from a pool is O(1).

Also, you have to make a distinction between interface speed and
implementation speed. Considering the stated goal of getting Boost into
the standard, it is (in my opinion) important that interfaces are
designed so that they _can_ be implemented in a highly efficient way, no
matter if the current implementation is efficient or not. For example,
std::stack::pop() does not return the object it pops, for performance
reasons.

That said, an interface cannot be made quirky and hard to use because
_some_ of the people that use it may require speed.

/Mattias

-- 
Mattias Flodin <flodin_at_[hidden]>  -  http://www.cs.umu.se/~flodin/
Room NADV 102
Department of Computing Science
Umeå University
S-901 87 Umeå, Sweden
--
"The optimist proclaims that we live in the best of all possible worlds, and
the pessimist fears this is true." -- James Branch Cabell

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk