C++ shared_ptr unfortunately is artificially slowed down by multithreaded synchronizations. The count in the control block is always updated atomically. But I frequently need to use them not because my data is shared by multiple threads, but because the ownership situation isn't static. Consider for example implementing a single-threaded persistent tree.

This means people frequently need to reinvent their own reference counting mechanisms.

Rust does this right. Rc and Arc.

To be fair, std::shared_ptr is just a high-level component that's a part of the STL. Although it's defined in the C++ standard, it's just a generic shared pointer implementation designed to be as robust and bullet-proof as possible.

As with everything in the C++ STL, if you care about bleeding edge performance then you should be prepared to use more perform any (and less generic) components, whether it's data structure implementations or shared pointers.

This is the quickest way to kill your performance in C++. I guarantee it wasn’t what Carmack was talking about.

I used sharedptr extensively in a game engine. Whoops: suddenly 20% of the frame time was gone, never to be recovered. Once that performance is gone it’s almost impossible to get it back, short of rewriting every system.

Only use shared_ptr when you actually want shared ownership. If you stick to unique_ptr for owning references and then "borrow" that raw pointer in functions, then you get speed without sacrificing too much safety and still no new/delete.

Additionally, shared ownership should be rare. Most objects should have a single owner that is responsible for them. This is not only better for performance, but also makes the system easier to understand.

Yes shared_ptr is relatively expensive; avoid it in your inner loops, but know that it's there for the other 80% of your code.

On the bright side, you didn't lose 200% of the frame time!

And, use unique pointers where possible. I see a lot of code using shared ptr where unique would suffice, even in my own code.

std::shared_ptr uses CAS atomics, which in heavy multithreaded code (multiple threads operating on the same pointers), can have surprising overhead in some situations.

On the other hand, not using atomics in heavy multithreaded code is just a recipe for disaster. The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.

> The problem with shared_ptr is the fact that it uses atomics even in single-threaded code, which is obviously an overkill.

On the other hand imagine the security issues if shared_ptr was not thread-safe - you could just not reliably destroy a shared_ptr in any thread.

If you really know that you're going to get a graph of shared_ptr that do not move of a single thread, you can use boost::local_shared_ptr explicitely.

One of the advantages of rust is its ability to segregate safe-to-share (between concurrent contexts) and not so, at compile time.

While it can’t (yet?) be generic over them, it lets you use the non-atomic Rc in thread-bound structures and know this is never going to be shared between threads, whereas the more expensive Arc can have handles be moved from one thread to an other.

Counterparts for Rc [1] and Arc [2] (and compiler enforcement of their safe use [3]) are available in C++, though not standard.

[1] https://github.com/duneroadrunner/SaferCPlusPlus#reference-c...

[2] https://github.com/duneroadrunner/SaferCPlusPlus#tasyncshare...

[3] https://github.com/duneroadrunner/scpptool