Boost Weak_Ptr: разрушение обходится дороже, чем ожидалось - PullRequest
Новая
       5

Boost Weak_Ptr: разрушение обходится дороже, чем ожидалось

6 голосов
/ 17 декабря 2010

По какой-то причине мы видим немалые затраты на уничтожение слабых указателей.Вот код виновника: 

~weak_count() // nothrow  
{  
    if(pi_ != 0) pi_->weak_release();  // Consumes a huge chunk of our time.
#if defined(BOOST_SP_ENABLE_DEBUG_HOOKS)  
    id_ = 0;  
#endif  
}

Мы не находимся в режиме отладки, и отладочные ловушки не задействованы.Слабый релиз отнимает поистине феноменальное количество времени.Это известная проблема?Мы что-то делаем не так?

Повышенная версия: 1.36
Компилятор: VS2008 Compiler Suite.

К сожалению, мы заблокированы в этой версии Boost по ряду причин, поэтому мне больше интересно, могут ли подобные странные расходы дублироваться в более новых версиях или представлять результат известной плохой практики.Мы уничтожаем только порядка 500 тыс. Слабых указателей, которые не должны давать заметной разницы в производительности от уничтожения аналогичного числа необработанных указателей.Конечно, не увеличение в 2,5-4 раза.Обратите внимание, что мы не удаляем объекты, на которые нацелены указанные указатели.Эти расходы связаны исключительно с уничтожением самих указателей.

Что здесь происходит?

Ответы [ 2 ]

4 голосов
/ 18 декабря 2010

weak_ptr нужно что-то вроде shared_ptr для реализации самого себя - потому что ему нужно уметь определять, существует ли еще указатель, ему нужна где-то структура с подсчетом ссылок, которая поддерживает свои собственные учетные записи.

Т.е., как weak_ptr определяет, существует ли объект по-прежнему, если счетчик ссылок не будет каким-либо образом доступен для его доступа? :)

Возможно, вам удастся обойтись без передачи необработанных указателей вместо weak_ptr s, если вам не нужно фактически когда-либо вступать во владение фрагментом кода, используя weak_ptr.

2 голосов
/ 18 декабря 2010

Скорее всего, цена исходит из атомарного уменьшения числа ссылок, которое довольно дорого по сравнению, скажем, с целочисленными присваиваниями, и может привести к кешу (или быть очень экстремальным, страница) промах / сбой, и бытьв атомарном операторе также могут возникать такие вещи, как недопустимость строк кэша.

Однако уничтожение необработанного указателя - это запрет, так что я не совсем уверен, что вы ожидали от слабого_птр, но это физически невозможноона может предложить ту же цену разрушения, если он предлагает какой-либо семантика уничтожения.

1004 * Равным образом, это более чем возможно, что вы утончаетесь перенапрягаете их.Указатели, обеспечивающие соблюдение прав собственности, не являются «серебряной пулей» - вам все равно нужно подумать о том, кому принадлежит объект.Широкомасштабное использование слабого указателя подсказывает мне, что вы на самом деле не продумали свою семантику владения.

Наконец, есть реализация shared_ptr и weak_ptr в MSVC 2008, в пространстве имен std :: tr1,Вы можете попробовать это.

...