c++ - ¿Cuál es la penalización de rendimiento de weak_ptr?

performance boost

Question

Actualmente estoy diseñando una estructura de objetos para un juego, y la organización más natural en mi caso se convirtió en un árbol. Siendo un gran admirador de punteros inteligentes, utilizo shared_ptr ''s exclusivamente. Sin embargo, en este caso, los niños en el árbol necesitarán tener acceso a su padre (ejemplo: los seres en el mapa necesitan poder acceder a los datos del mapa, es decir, los datos de sus padres).

La dirección de ser propietario es, por supuesto, que un mapa posee sus seres, por lo que tiene indicadores compartidos para ellos. Para acceder a los datos del mapa desde dentro de un ser, sin embargo, necesitamos un puntero al padre: la forma del puntero inteligente es usar una referencia, ergo a weak_ptr .

Sin embargo, una vez leí que bloquear un weak_ptr es una operación costosa, tal vez eso ya no sea cierto, pero teniendo en cuenta que el weak_ptr se bloqueará con mucha frecuencia, me preocupa que este diseño esté condenado a un bajo rendimiento.

De ahí la pregunta:

¿Cuál es la penalidad de rendimiento de bloquear un weak_ptr? ¿Qué tan significativo es?

Answer 1

Del código fuente de Boost 1.42 ( <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, el comentario de James McNellis es correcto; es el costo de copiar y construir un shared_ptr .

Answer 2

para mi propio proyecto, pude mejorar el rendimiento drásticamente al agregar #define BOOST_DISABLE_THREADS antes de #define BOOST_DISABLE_THREADS cualquier impulso. Esto evita la sobrecarga spinlock / mutex de weak_ptr :: lock que en mi proyecto fue un importante cuello de botella. Como el proyecto no es multiproceso, wrt boost, podría hacer esto.