[boost] Re: Performance: shared_ptr

From: Matthew Wilson (stlsoft_at_[hidden])
Date: 2003-11-17 20:24:45

"David B. Held" <dheld_at_[hidden]> wrote in message
news:bpbngm$uq9$1_at_sea.gmane.org...
> "Matthew Wilson" <stlsoft_at_[hidden]> wrote in message
> news:bpb8lg$n4m$1_at_sea.gmane.org...
> > [...]
> > Not the general principle of having the reference-count
> > external to the counted type, but the specific technique of
> > having it a heap-allocated (integer) instance. That seems,
> > to me anyway, the essence of the shared_ptr, and the bit
> > that's conceptually beautiful (albeit potentially slightly
> > inefficient).
>
> Just out of curiosity, how else do you implement an external
> count?

In a shared-pool of counters. That's what the last (#5) of the ptr-types
examined does.

The one I've done is a very brain-dead thing, that just has 1024 longs in an
array. The (thread-safe) pool class simply allocates them in turn and
maintains a count of the number allocated. Once it's 1024, all subsequent
counters are allocated from the heap. Only when all counters are returned
does the pool allocate from the array again.

As I said, it's brain-dead, and was just written like that to exemplify the
concept. The performance figures demonstrate that it provides a significant
benefit until the number of outstanding references > 1024, at which point it
the optimisation turns into pessimisation.

A more complex solution could have one or more arrays, and the array element
could be a struct { rc_type rc; rc_type is_used } and the allocation can use
a combination of total-count (per-array) and atomic operations on the
is_used member. I wrote something similar to that for very fast allocation
of memory blocks in a threaded comms server many moons ago, and it gave
surprisingly good performance, but the costs/benefits of allocating large
chunks of memory may not translate to the allocation of a simple
reference-count. I wouldn't like to hazard a guess.

Of course, you've now got me interested. I may have a go at that, if I can
squeeze the time ...