Запустить профилирование C++ кода по кнопке.

Не надо gprof, надо valgrind + kcachegrind. И они умеют то, что вы хотите, читайте ман по valgrind.

valgrind вообще мало желателен, ибо там жесточайше огромные массивы данных перерабатываются. Даже просто в -O0 режиме собранная софтина заставляет нервно курить, а валгринд будет полдня работать...

Можно тогда perf попробовать, он на производительность мало влияет.

А почему gprof - это плохо-плохо? Я правда юзал его мало: лет 5 по разу в год, он быстро рисует топ по пожиранию времени. В чём его проблема?

Я не вижу в нём ничего особо плохого. Не сильно удобно, что надо перекомпилитовать под него приложение, и то, что он сам влияет на результат измерений в какой-то мере. Вроде, ничего принципиально плохого в нём нет.

Ага, спасибо. А как устроен perf, что перекомпиляции не требует?

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

Он профилирует сэмплированием. Ядро смотрит на то, в какой функции процесс находится периодически (по таймеру или при переходе в режим ядра) и на основе этого делает выводы. Ему только отладочные символы нужны, чтобы понять в какой функции идёт работа. Это несколько менее точное изменение чем gprof с его инструментированием, но зато производительность не страдает.

А-а-а, точно. Т.е. он юзает способ с дебажным прерываним (int 3h) как gdb?

Не уверен что его можно в середине работы программы заставить вскочить

У perf record есть опция --pid, т.е. его можно подключить к процессу после старта. Это не из кода, но может будет достаточно.

В том что абсолютно не совместим с тредами, например.

Нет. Он сидит в ядре и просто периодически записывает что происходит.

А «совместим с тредами» - это что означает физически?

Он просто «не знает» что в программе существую треды и, соответственно, покажет тебе абсолютно бессмысленный результат. Вот тут человек, который не понимает сигналы, пытается это дело «пофиксить»: http://sam.zoy.org/writings/programming/gprof.html Бессмысленно и беспощадно.

gperftools работает по тому же принципу (опираясь на ITIMER_PROF), но вроде как должен уметь треды. Можешь посмотреть его реализацию.

А вообще юзай perf.

valgrind

Для профилирования? Смеёшься? Нет, конечно можно, но только получится полная ерунда, если в программе есть IO.

Самая адекватная утилита для профайлинга в linux — perf.

http://www.rotateright.com/

Жаль, что они загнулись, но софтина вполне актуальна и юзабельна.

http://valgrind.org/docs/manual/cg-manual.html

привет

Intel® VTune™ Amplifier уже советовали? Под лин не использовал, но под вендой торт.

Да. Сам свою ссылку читал?

5.8.3 не мешает быть ему лучшей возможной утилитой для профилирования. Если не ошибаюсь, та проприетарная поделка от интела работала по тому же принципу.

Нет, не по такому же. Подсказка:

1) Valgrind запускает твою программу в неком подобии VM 2) Это даёт оверхед раз в 20 3) Ядро при этом не под valgrind'ом работает 4) Есть такая замечательная вещь, как сисколлы

Теперь понятно, почему область применения cachegrind/callgrind очень сильно ограничена, и если твоя программа не только перемножает сферические гармоники в вакууме, то они показывают что угодно, но только не хотспоты?

Perf/Vtune работают иначе.

я давным давно под линём юзала. было вполне юзабельно. а теперь у них компилер для линюкса со всеми этими инструментами стал не бесплатным и свободным для всех и я как-то забила на icc.

Под вендой VTune юзал, но уже давно не подвендой...

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

Ну попробуй и расскажешь нам потом.

а теперь у них компилер для линюкса со всеми этими инструментами стал не бесплатным и свободным для всех и я как-то забила на icc.

Intel provides select Intel® Software Development Products at no cost to qualified open source contributors who are working on open source projects compliant with the Open Source Initiative (OSI).

Qualifications:

- Developers must be actively contributing to an open source project (e.g. GitHub)

- Agree to terms and conditions of the Intel Non-Commercial License

Может ОПу и подойдет.

Запускай Valgrind с ядром в юзерспейсе, проблем-то. Оверхед в данном случае не имеет совершенно никакого значения, статистика полученная таким образом более чем адекватна.

Феерический бред какой-то.

Есть как минимум 1 путь - отладка в виртуальной машине :-) Хрен знает, насколько реализуемо и юзабельно (скажу честно - мой опыт работы с kernel space закончился мыслью «ну его нахер» и костылями вокруг другой софтины), но по идее - логичный способ юзать всё, что должно работать в kernel space (особенно, если есть возможность подсунуть нужный ввод нужного девайса/etc).

Я раньше пользовался еще не упомянутым в топике oprofile. Но там тож нет «кнопки».

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

И да, я нигде не говорил, что оверхеда не будет.

Внешний мир ты тоже в виртуальную машину засунешь?

В нашей конторе запускали как-то по приколу callgrind.

Во-первых, сразу же пришлось подкручивать всякие poll reply интервалы, т.к. из-за оверхеда инструментации код работал так медленно, что супервизор считал процесс зависшим и периодически ребутал его. Профилировать можно было только на минимальной загрузке, т.к. дальше включались overload protection-механизмы.

...В итоге callgrind радостно показал, что, грубо говоря, 90% времени приходится на разбор пакета. Нормальный же профайлер показывал, что 99% времени процесс тупо ждёт эти пакеты из сокета.

Оверхед инструментации для меня, по крайней мере — deal breaker. Может где-то это будет не важно, но для себя я применений этому инструменту просто не вижу.

Внешний мир ты тоже в виртуальную машину засунешь?

Это было одним из аргументов в пользу «ну его нахер» - я вроде и нашёл, как подсунуть необходимый ввод девайса, но ниасилил.

Ясно.

с внешними девайсами такое работать не будет. надо писать обёртки и заглушки для тестов.

Ну ясное дело. В общем-то, я примерно в это и пытался - потестить на определенных заранее известных примерах ввода/вывода

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

Ну, слава Ктулху - в моём случае девайс был каким-то крайне простым. Можно было вручную всё это проделать.

который собирал логи сигналов с работающего железа и потом запускали это в «плеере», который скармливал сигналы на нужные порты, шины и т.д

Что за задача такая, где нет обратной связи?

например, сетевой диод?

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

собирал логи сигналов с работающего железа
потом запускали это в «плеере», который скармливал сигналы на нужные порты, шины
[обратная связь] есть, конечно

Не понимаю. Какая обратная связь может быть с записью?

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

...В итоге callgrind радостно показал, что, грубо говоря, 90% времени приходится на разбор пакета. Нормальный же профайлер показывал, что 99% времени процесс тупо ждёт эти пакеты из сокета.

Круто, конечно, но непонятно, пригоден-таки callgrind оказался для профилирования разбора пакета, или нет?

Даже если и пригоден, поинт не в этом, а в том что тезис о том что он является «лучшей возможной утилитой для профилирования», очевидно, неверен. Как, впрочем, и детский лепет о том что «для профилирования не нужны абсолютные величины».

Нет конечно. Какой профит оптимизировать то, что занимает 1% времени? В итоге улучшили протокол и радовались.

P.S. Ну и поскольку из-за тормозов мы не смогли профайлить на сколько либо серьёзной нагрузке, то смысла в callgrind не было от слова совсем.

Алгоритмы ведь все имеют разный порядок роста. На низкой нагрузке, допустим у тебя тормозит плохо написанный линейный алгоритм, а на высокой начнёт выделяться хорошо написанный логлинейный. Но ты этого не увидишь, т.к. оверхед профайлера не даст тебе выйти в эту область.

P.P.S. Ну и callgrind не может залезть в ядро, что тоже часто полезно для задач связанных с IO.

sysprof