[boost] Re: Smart Pointer Timing Test Results

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-01-31 18:02:53

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> -----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 
> to
> > 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
> 1) 
>

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.

Mark Borgerding 
markab (at) xetron . com
Software Engineer
Xetron Corporation
 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com>

iQA/AwUBOJYUnv9Ej8AEXMygEQITcACeJrEk7H4/ZDkRj4NuIEXuPycfdrUAn0Nr
G6/u6p5FwRmiJnS2eP+QYmzh
=wm+M
-----END PGP SIGNATURE-----