Boost logo

Boost Users :

Subject: Re: [Boost-users] [iostreams] Devices and WOULD_BLOCK
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-01-26 21:08:39

On 27 Jan 2015 at 10:58, Gavin Lambert wrote:

> There are negative performance consequences to copying a shared_ptr (ie.
> incrementing or decrementing its refcount). *Most* applications don't
> need to care about this (it's very small) but sometimes it's worthy of
> note, and there's no harm in avoiding copies in silly places (which is
> why I thwack people that pass a shared_ptr as a value parameter).

As food for thought, AFIO which uses shared_ptr very heavily indeed
to avoid any locking at all passes them around all by value. It was
bugging me whether this was costing me performance, so I tried
replaced the lot with reference semantics.

Total effect on performance: ~0.1%.

The key is that AFIO very, very rarely has more than one thread touch
a shared_ptr at once. That, on Intel at least, makes their atomic
reference counting almost as cheap as non-atomic reference counting.
Combine that with the compiler judiciously folding out copies for you
where it can, and the overhead for the benefits to debugging and
maintenance is irrelevant.

Of course, I'm currently seeing a 300k CPU cycle per op average.
shared_ptr is tiny compared to that. With a 10k CPU cycle per op
average I might care a bit more.


ned Productions Limited Consulting

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at