[gclist] Daily gclist MIME digest V4 #28

[Mark Hamburg]

on 2/20/03 2:20 AM, gclist-owner@lists.iecc.com at
gclist-owner@lists.iecc.com wrote:

> Also, in environments that mix reference counting with unmanaged heaps,
> such as COM development on Win32, you must also account for the time
> spent in AddRef and Release.  Most thread-safe implementations use
> interlocked integer primitives, which are quite costly on SMP machines.
>
> I've done a fair amount of profiling of real-world server apps on Win32,
> and in many implementations, SMP scalability is severely hindered by the
> very high frequency of interlocked operations.  In services that make
> heavy use of COM interfaces, reference counting is often one of the
> biggest users of interlocked access.

I can believe that naïve reference counting is expensive. I've worked on
projects that go through a fair number of moderately unsafe contortions to
avoid needless increments and decrements.

The best scheme I've seen so far for dealing with this -- particularly in a
non-GC friendly environment -- has probably been what Apple (NeXT) did in
Cocoa (NeXTStep) with the autorelease pools.  These allow most references on
the stack to be passed around with no need to increment or decrement
pointers. I suspect that most naïve implementations of COMPtr or RCPtr
templates in contrast increment and decrement the count on each
construction, destruction, and assignment. If you pass through a lot of
subroutines, that gets very expensive very quickly.

Mark