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/