[boost] Re: Proposals: faster pointers & postponed construction type

From: David B. Held (dheld_at_[hidden])
Date: 2002-07-21 18:52:52

"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
news:ahf9c4$4h6$1_at_main.gmane.org...
>
> 1) I wanted to show you a benchmark showing shared pointer
> differences between squad_ptr<> and shared_ptr<>.

Again, you're comparing apples to oranges.

> shared_ptr<> is not derived from counted_base because I wanted to
> point out that squad_ptr<> is easier to use with typenames like int,
float,
> ...  and keeps its rapidity.

No, shared_ptr<> is not derived from counted_base because that's the
way the library designers wrote it. ;)

> Compilation of
> 'g++ -lrt benchmark.cpp' on Intel 1.4 GHz reports:
>
> Ressources required by shared_tr<>:
> [...]

These numbers are misleading, because if size is important, then you
use a boost::intrusive_ptr and wrap the type in a count wrapper (like
your prefix<> class, even).  At that point, one sees that squad_ptr and
intrusive_ptr are the same size.  On the other hand, shared_ptr does
not require a complete type, whereas squad_ptr does.  I believe that
intrusive_ptr also does not require a complete type (though it would
if it used something like your prefix<> template, of course).

> list shared_ptr<> took 3303000 nanoseconds to construct.
> list shared_ptr<> took 2424000 nanoseconds to copy.
> list shared_ptr<> took 2612000 nanoseconds to destroy.
> [...]
> list squad_ptr<> took 1251000 nanoseconds to construct.
> list squad_ptr<> took 979000 nanoseconds to copy.
> list squad_ptr<> took 1262000 nanoseconds to destroy.

So your pointer is 2-3 times faster than shared_ptr<> on your platform.
It doesn't support weak pointers, custom deleters, or a thread-safe
count.  It also does not support array semantics.  Again, you're
comparing apples to oranges.  Maybe some people do need a pointer
that is just that fast.  Still, I would be suprised it managed to join
the menagerie that is currently boost::smart_ptr.  The benefits just
don't seem compelling, compared to the costs.

The costs include peculiar usage (creating a squad pointer is surely
bizarre to people used to raw pointers and most other smart pointers)
and small functionality set.

> [...]
> 3) testplist.cpp shows another advantage of using prefix<> when
> nodes of a list are instanciated.  You won't need pointers.

This is fine and good if people are willing to give up std::list and its
familiar interface in favor of your stripped down, highly unusual list
and its interface.  I guarantee you'll scare the pants off a good deal
of programmers by making them invoke operator new just to add
elements to your list.  Of course, you can resort to macros to help
that out, but then your code starts to turn into a macro header
instead of a template header.

Dave