Чем лучше всего профилировать Qt-ешные программы?

[OKTA]

Нашел тему про shared_ptr. http://stackoverflow.com/questions/3628081/shared-ptr-horrible-speed
Правда ли?

[Bepec]

Конечно медленнее. Там же внутри обертка с счётчиком.
Делали проект по приёму данных с оптоволокна - пришлось выкинуть нафиг все эти крутости аля "boost::shared_ptr". Ибо даже 10Гбит принять не могли - тормозило.

[Old]

Делали проект по приёму данных с оптоволокна - пришлось выкинуть нафиг все эти крутости аля "boost::shared_ptr". Ибо даже 10Гб принять не могли - тормозило.

Мне даже страшно представить что вы с ними делали.
Покажите пожалуйста как вы их использовали при приеме данных?

[Bepec]

Не я, а коллега, яро доказывающий что обычный указатели - сакс, а shared - крутотень!

Задача простая была - приём структур, анализ, отбраковка, передача "чистых" данных дальше.

[Old]

Задача простая была - приём структур, анализ, отбраковка, передача "чистых" данных дальше.

Вот это и не понятно. Как он использовал shared_ptr в этой задаче, что была просадка в скорости?
Где здесь происходит интенсивная работа с указателями?

[Bepec]

Везде где использовались указатели - данные. Структуры создаваемые из данных и иже с ним.

[Old]

Везде где использовались указатели - данные. Структуры создаваемые из данных и иже с ним.

Это не убедительно. У меня (да и не только у меня) они используются в проектах с очень высокой нагрузкой и спокойно выдерживаю. Не представляю как указатели могут стать "бутылочным горлышком" при приеме и обработке данных.
Получается, что у вас создание/использование указателя соизмеримо с самой обработкой?

[_OLEGator_]

Конечно медленнее. Там же внутри обертка с счётчиком.

Можно подумать, что счетчик синхронизируется с сайтом майкрософт.

[Igors]

поэтому оставляю линк на статью,

Очень понравилось. В основном чтение статей сводится к запоминанию инфы (часто без всякого осмысления). Здесь пытаются пробудить "соображалку"

Является ли 64-битное чтение / запись атомарной операцией?

За это допущение я получал  В общем случае нет, адрес может быть не кратен 8. И вообще присваивание long long компилятор может выполнить как 2 int'ов. Поэтому строго tbb::atomic

class AbstractAction {
public:
AbstractAction(Executor *executor) {
executor->add(this);
...
}
...
virtual void Run() = 0;
}

Ну тут очевидно - родительский конструктор еще не вызван, а executor уже щемится

Однако о др вещах я без понятия - напр что то за "shadow" 

[Igors]

Получается, что у вас создание/использование указателя соизмеримо с самой обработкой?

Такие случаи возможны (напр при работе с геометрией) - хотя не так уж часты

[Old]

Такие случаи возможны (напр при работе с геометрией) - хотя не так уж часты

Покажите на примере. Только не нужно предлагать "синтетику".
На синтетических тестах я могу показать, что и вызовы виртуальных методов сильно тормозят выполнение или конструкторы/деструкторы. Но в реальной жизни мы подобные издержки либо игнорируем, либо обходим изменяя алгоритм.

В данном же случае, мы говорим про работу с сетью (прием/обработка/отправка), представляете задержки? Могут они быть соизмеримы?

[Igors]

Покажите на примере. Только не нужно предлагать "синтетику".

Так вот же и привели (знакомая задача)

Нашел тему про shared_ptr. http://stackoverflow.com/questions/3628081/shared-ptr-horrible-speed

В данном же случае, мы говорим про работу с сетью (прием/обработка/отправка), представляете задержки? Могут они быть соизмеримы?

Та ну..  Зачем такие крайности? На всякое правило найдется исключение, это нормально

[Bepec]

Я не могу предоставить вам тест, ведь у меня теперь нет ПЛИС'а, щемящего поток инфы по оптоволокну

[Old]

Так вот же и привели (знакомая задача)

Знакомая, только не понятно для чего автор использовать умный указатель со счетчиком? Это избыточно, есть другие умные указатели.

И как раз про такие задачи я и писал:

Но в реальной жизни ... обходим изменяя алгоритм.

Для быстрого выделения одинаковых объектов лучше использовать пулы + unique_ptr, и это решение обгонит обычные указатели.
Самый большой прирост дает именно алгоритмическая оптимизация, а не отказ от конструкторов/деструкторов и умных указателей.

Та ну..   Зачем такие крайности? На всякое правило найдется исключение, это нормально

Вы про какие крайности?

[Igors]

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

Все верно, только "отказ" надо заменить на "использование"  Алгоритм там примерно такой
 
Нужно построить треугольники по множеству точек на плоскости. Строим вмещающий треугольник, затем добавляем в него точку за точкой. Добавленная попадает в какой-то треугольник, он разбивается на 3 новых. Затем ребра балансируются по Борису Николаевичу. Балансировка может вызвать изменение смежных тр-ков, в общем получается "волна" которая впрочем быстро затухает. Где-то видел анимацию видео, но навскидку не найду.

В общем типичная задача где у "грамотного" возникают проблемы Знает-то он может и много, но вот возиться со всем этим не хочет.  Бросается "изыскивать" готовое - что далеко не всегда приемлемо. А оптимизировать самому - так это ж велосипед! Умные указатели, bidirectional iterators и.т.п. - все это здесь "до одного места", знаток "не в своей тарелке" . Поэтому человек с куда более скромными познаниями - но делающий задачу охотно, с желанием добивается лучших результатов.

Да, по поводу "балансировки", базовая задача:

Есть выпуклый 4-угольник  на плоскости. Каким образом лучше разбить его на 2 треугольника?  Др словами сформулировать критерий/правила "лучше"