Re: [Boost-users] [iostreams] Devices and WOULD_BLOCK

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.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/