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

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

• Valgrind (И связанные с ним инструменты, такие как cachegrind и т. Д.)
• Инструменты производительности Google

Есть несколько способов сделать это.

Не забывайте метод без профилировщика.

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

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

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

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

Я знаю, это нелогично.

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

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

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

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

ПРИМЕЧАНИЕ: Я только что просмотрел Люка Стакуокера, и применимы те же замечания. Я думаю, что он на правильном пути, но требует доработки пользовательского интерфейса.

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

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

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

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

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

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

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

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

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

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

---

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

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

---

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

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

---

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

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

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