问题
I'm currently designing a object structure for a game, and the most natural organization in my case became a tree. Being a great fan of smart pointers I use shared_ptr's exclusively. However, in this case, the children in the tree will need access to it's parent (example -- beings on map need to be able to access map data -- ergo the data of their parents.
The direction of owning is of course that a map owns it's beings, so holds shared pointers to them. To access the map data from within a being we however need a pointer to the parent -- the smart pointer way is to use a reference, ergo a weak_ptr.
However, I once read that locking a weak_ptr is a expensive operation -- maybe that's not true anymore -- but considering that the weak_ptr will be locked very often, I'm concerned that this design is doomed with poor performance.
Hence the question:
What is the performance penalty of locking a weak_ptr? How significant is it?
回答1:
From the Boost 1.42 source code (<boost/shared_ptr/weak_ptr.hpp> line 155):
shared_ptr<T> lock() const // never throws
{
return shared_ptr<element_type>( *this, boost::detail::sp_nothrow_tag() );
}
ergo, James McNellis's comment is correct; it's the cost of copy-constructing a shared_ptr.
回答2:
for my own project, I was able to improve performance dramatically by adding
#define BOOST_DISABLE_THREADS before any boost includes.
This avoids the spinlock/mutex overhead of weak_ptr::lock which in my project was
a major bottleneck. As the project is not multithreaded wrt boost, i could do this.
来源：https://stackoverflow.com/questions/2748091/whats-the-performance-penalty-of-weak-ptr