Рекомендуемые профили Open Source

Ответ 1

Вы можете попробовать Инструментарий производительности Windows. Полностью свободен в использовании. В этой записи есть пример того, как делать профилирование на основе образца.

Ответ 2

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

Ответ 3

Здесь более одного способа сделать это.

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

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

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

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

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

Это контр-интуитивное, я знаю.

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

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

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

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

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

Ответ 6

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