From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-01-31 18:02:53
-----BEGIN PGP SIGNED MESSAGE-----
> -----Original Message-----
> From: Miki Jovanovic [mailto:miki_at_[hidden]]
> Sent: Monday, January 31, 2000 4:36 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Smart Pointer Timing Test Results
> "boris fomitchev" <fb-_at_[hidden]> wrote:
> > What drawbacks ? I see only advantages -
> > 1) it bypasses global memory manager (if you need synch, you add
> > one
> > the
> > free list only). Or do you mean one still has to implement
> sync ? This
> > is not a drawback of the approach, it's implementation issue.
> > 2) it speeds up the allocation and uses the least amount of
> > memory possible.
> I am not knocking the linked pointer down, but just pointing it is
> not best for every test case. If you want a list form, what I think
> is certain from all of our discussion is:
> 1) it has slowest copy opperation
> 2) it is approx. three times larger then intrusive ptr (3 words vs
I think that for nearly all applications, linked_ptr would be a
better choice. The only exception in my opinion is the case where
the memory footprint of the smart pointer must remain small.
I don't think that the coy/assignment performance is really that much
of an issue. Remember -- copy constructors need to outnumber
dumb-pointer constructors by more than 20:1 before a shared_ptr gets
equivalent performance to linked_ptr.
On one end of the spectrum (with no copy c'tors, or assignments),
linked_ptr is about 7 times more efficient than shared_ptr.
On the other end of the spectrum, (as the number of copy constructors
and assignments tend toward infinity)
shared_ptr becomes about 5 times as efficient as linked_ptr.
The above ratios are based upon the timing comparisons of assignment,
copy construction, and dumb-pointer construction that I posted to the
list on Saturday. Some numbers that others have posted skew the
argument even higher in linked_ptr's favor.
By weighing the best case, worst case, and typical case scenarios. I
think linked_ptr comes out the winner.
[curious George goes off and writes some code ...]
I wanted to see some concrete numbers comparing varying ratios of
constructors to copies. I built a little test app. These are the
results using MSVC6 on a P2 450. I have attached the files, I'd be
interested to see what the results are on different platforms, I can
try it at home later tonight (gcc 2.95 ,linux pentium 200).
P = the number of smart pointer constructions from a pointer
C = the number of smart pointer copy constructions, derived from that
original smart pointer
L = the avg elapsed time using a linked_ptr (in microseconds)
S = the avg elapsed time using a shared_ptr (in microseconds)
Note: the elapsed time also includes the allocation of an int on the
heap -- this is the resource that will be tracked.
P C Linked Shared
1 1 1.15 1.87
1 8 1.33 2.35
1 64 3.25 3.94
1 512 18.4 16.66
1 4096 140.6 118.5
So it seems that even at >512 copies, linked_ptr is still faster.
And at 4096 copies, shared_ptr shaves about 9% off linked_ptr's time.
I've done some hacking on linked_ptr.hpp. I don't think I've done
anything that would cause huge differences in performance, but I've
included it all the same.
BTW, I've also included a relatively alpha version of a shared
pointer that holds a pointer to a struct,
so sizeof(sh_ptr) == sizeof(void*). If someone wanted a small memory
footprint, this would be the way to go.
markab (at) xetron . com
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk