[boost] Re: Smart Pointer Timing Test Results

From: Gavin Collings (gcollings_at_[hidden])
Date: 2000-02-01 06:19:07

I re-ran your code on my machine (after moving the elapsed function out
of the output statement to avoid timing writes to cout) with Dave's
fast shared_ptr (this is the one we should really be interested in now)
- results first (in micro-seconds), then a few comments:

        Linked           Fast Shared          Shared
1         2.5              2.7                  4.8
2         2.1              2.8                  4.9
4         2.3              3.0                  5.1
8         3.0              3.4                  5.5
16        3.8              4.2                  6.2
32        5.5              5.7                  7.7
64        8.9              8.7                 10.7
128      15.6             14.7                 16.8
256      29.1             26.8                 28.9
512      56.3             51.0                 53.4
1024    110.3             99.2                101.5

- Sadly I only have a PII 220 so my times are a little longer than
yours :(

- All of the above times include the allocation and deallocation of the
contained raw pointer.  From these results (and my tests yesterday) it
looks like this is of the order of 2.0 - 2.1 us.

- The difference in time between shared_ptr and fast shared_ptr is
about 2.0-2.1 us.  This corresponds to the time taken to allocate a
long on the heap - in agreement with the previous point.

- The test only uses copy construction as a measure of copy operation -
this biases it slightly toward linked_ptr, since assignment is more
complex for linked_ptr.  It may not be that unfair though, as parameter
passing uses copy initialisation so in practice it may be used more
anyway.

- The previous has pushed out the cross over point between linked_ptr
and fast shared_ptr to around 30-40 operations.  Averaging this with
yesterday's result probably puts the cross over at about 20 or so for
realistic average usage.

- But the difference between them is much less than that between
linked_ptr and shared_ptr. (Much less when you take out the 2.0 us of
unavoidable "overhead")

At first sight it looks as though there is little to choose between
linked_ptr and fast shared_ptr.  For me, though the two strategies have
different characteristics.  The ones that come to mind are: -

- multi-threaded synchronisation:  shared_ptr is likely to be a winner
here, since the "sharing information" is concentrated in the reference
count, rather than spread out across objects.

- deterministic operation time: here linked_ptr is likely to show a
much narrower spread of operation times than anything relying on a
memory allocator.

I think there's room for both implementations.  But maybe it's time to
revisit the parameterize by allocator<> debate - and someone had the
idea of using template member functions to construct the contained
pointer...

Gavin.