From: Bud Millwood (budm_at_[hidden])
Date: 2006-01-31 12:16:21
> > Mine. Tested and found with Quantify, and although it was our own
> > policy-based smart pointer, the mutex locking was the high peak on the
> > graph. I halved my app's response latency by using a single-threaded
> > smart pointer in a multi-threaded app.
> Which of course is precisely the right time to start making
> oprimisations - after you've profiled it and found it to be a problem.
> Still I'm curious about this though, why was your code copying so
> many smart pointers?
This was a policy-based smart pointer that performed method-level locking
before going into the pointee. No copying going on. Not a boost smart
In fact, I'm definitely not qualified to comment on the boost smart pointers
per-se, since I've never used them, but I wanted to put in my two cents worth
in about a single smart pointer class that uses orthogonal policies. That's
what we're using, with policies for copying (ctor/clone), method locking,
object locking (intrusive/non-intrusive) and ownership (MT/ST,
> Also I wonder if you had tried the shared_ptr lock free locking
> (huh?!?) you'd have noticed similar (but obviously not *as* good)
> perfomance gains?
Not using the boost smart pointers.
> In general I agree - I'm dead against macros to enable/disable
> features. But I also find using complex policy classes equally
> annoying. Default template parameters get you so far, but have
> problems of their own.
> I'd prefer a really explicit separate class called
> shared_ptr_no_threads<> or something. They have very different
> behaviour, they should be called different things.
Yeah, they have different behavior, but that's the point, really. You have one
code base that invokes policies, without really knowing what the policies are
Here's a link to the one we're using: