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
That said, an interface cannot be made quirky and hard to use because
_some_ of the people that use it may require speed.
-- 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