Рекомендуемые профилировщики с открытым исходным кодом [закрыто]

• Valgrind (и связанные с ними инструменты, такие как cachegrind и т. д.)
• Google performance tools

Есть более чем один способ сделать это.

Не забывайте о методе no-profiler.

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

Эти приоритеты можно поменять местами. Т. е. проблема может быть расположена по точному адресу машины, в то время как точность стоимости зависит от количества образцов.

Большинство реальных проблем стоят не менее 10%, где высокая точность не имеет существенного значения.

Пример: если что-то заставляет вашу программу работать в 2 раза дольше, чем она должна, это означает, что в ней есть какой-то код, который стоит 50%. Если вы возьмете 10 образцов стека вызовов, пока он работает медленно, точная строка(строки) кода будет присутствовать примерно на 5 из них. Чем крупнее программа, тем более вероятно, что проблема заключается в вызове функции где-то в середине стека.

Это противоречит интуиции, я знаю.

Примечание: xPerf почти там, но не совсем (насколько я могу судить). Он берет образцы стека вызовов и сохраняет их - это хорошо. Вот что, я думаю, ему нужно:

• Он должен брать образцы только тогда, когда вы этого хотите. Как бы то ни было, вы должны отфильтровать несущественные.

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

• Если вы нажмете, чтобы получить вид бабочки, центрированный на одной инструкции вызова или инструкции leaf, должен показывать Вам не фракцию процессора, а фракцию образцов стека, содержащих эту инструкцию. Это было бы прямой мерой стоимости такой инструкции, как доля времени. (Может быть, он может сделать это,я не мог сказать.) Так, например, даже если инструкция была вызовом file-open или чем-то еще, что задерживает поток, она все равно стоит времени настенных часов, и вам нужно знать тот.

Примечание: Я только что посмотрел на Люка Стакуокера, и те же замечания применимы. Я думаю, что это на правильном пути, но нуждается в UI работе.

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

Можно возразить,что если бы информация о номере строки была сохранена, она бы быстро закончилась. Два ответа. Один) Есть только так много линий, которые появляются на образцах, и они появляются неоднократно. 2) требуется не так много выборок - предположение о необходимости высокой статистической точности измерений всегда предполагалось, но никогда не оправдывалось.

Я подозреваю, что другие образцы стека, такие как xPerf, имеют аналогичные проблемы.

Это не открытый исходный код, но AMD CodeAnalyst свободен. Он также работает на процессорах Intel, несмотря на название. Существуют версии, доступные как для Windows (с интеграцией Visual Studio), так и для Linux.

Из тех, кто перечислил, я нашел, что Люк Стакуокер работает лучше всего - мне понравился его графический интерфейс, его было легко запустить.

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

---

Проведя с ними еще некоторое время, я обнаружил один довольно важный недостаток. В то время как оба пытаются выполнить выборку с разрешением 1 мс, на практике они не достигают этого, потому что их выборка метод (StackWalk64 присоединенного процесса) слишком медленный. Для моего приложения требуется что-то вроде 5-20 мс, чтобы получить callstack. Это не только делает ваши результаты неточными, но и делает их искаженными, так как короткие колл-стэки проходят быстрее, поэтому имеют тенденцию получать больше хитов.

Мы используемLtProf и были довольны этим. Не с открытым исходным кодом, а только $$, не $$$ : -)