On 27 Jan 2015 at 19:51, Gavin Lambert wrote:
As I said, it's not a big difference (atomic ops are typically ~1us, and that was on the previous CPU generation), but it's still one of my pet peeves, as while there are many places where shared_ptrs do need to get copied for correctness, parameter passing is not one of those places. (And performance gets worse if you end up passing the object through many layers as part of keeping methods short or similar "tidiness" or abstraction guidelines; and it wastes more stack too.)
A good compiler optimiser will collapse those if the code is header only. In AFIO's case it does exactly that - five nested function calls each taking by value shared_ptr turn into a single shared_ptr copy only.
You're going to have to make lots of copies anyway in an asynchronous library like AFIO, because binding an asynchronous callback is one of those places that you *do* need to copy a shared_ptr, so if you have a high percentage of async code (which is what I would expect with that sort of library) then it's not going to make much difference either way.
You're right in general, and in AFIO until v1.3 of the engine. In v1.4 I'm going even more intrusive, and I expect to elide all but necessary copying completely in the main engine loop. I will do this via the batch detachable and reattachable node_ptr support in my concurrent_unordered_map, basically you can detach and recycle op state rather than ever allocating or deallocating. This should let me stop pinning shared_ptrs to their callbacks as the new custom future implementation will tag a shared_ptr exactly once for you.
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.
I'm probably biased the other way, because about half of the code I work on has sub-millisecond budgets. :)
300k CPU cycles is still 0.1ms. But no, it's the stochastic variance that upsets me. I want a worst case latency of 0.1ms, then I would be pleased I think. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/