Профайлер, основанный на выборке времени Linux

короткая версия:

Есть ли хороший профилировщик выборки для свободного времени для Linux?

длинная версия:

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

Проблема заключалась в сложном цикле, порождающем С++ filter, чтобы развернуть имя С++. Я случайно наткнулся на код, преследуя еще одно узкое место. OProfile не показал ничего необычного в коде, поэтому я почти проигнорировал его, но мой смысл кода подсказывал мне оптимизировать вызов и посмотреть, что произошло. Я изменил popen фильтра С++ на abi::__cxa_demangle. Среда длилась от минуты до нескольких секунд. Около x60 ускоряется.

Есть ли способ, которым я мог бы настроить OProfile для обозначения вызова popen? Поскольку данные профиля находятся сейчас, OProfile считает, что шея бутылки была кучей и std::string вызовов (которые BTW после оптимизации уменьшали время выполнения до менее секунды, больше, чем x2).

Вот моя конфигурация OProfile:

$ sudo opcontrol --status
Daemon not running
Event 0: CPU_CLK_UNHALTED:90000:0:1:1
Separate options: library
vmlinux file: none
Image filter: /path/to/executable
Call-graph depth: 7
Buffer size: 65536

Есть ли еще один профайлер для Linux, который мог бы найти узкое место?

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

Если я не могу исправить это, OProfile будет полезен только тогда, когда исполняемый файл нажимает около 100% CPU. Он не может помочь с исполняемыми файлами, которые имеют неэффективные блокирующие вызовы.

ОТВЕТЫ

Ответ 1

Рад, что вы спросили. Я полагаю, что OProfile можно сделать так, чтобы я считал нужным, то есть брать образцы стека в режиме настенных часов, когда программа работает медленно, и если она не позволит вам рассматривать отдельные образцы стека, по крайней мере суммируйте для каждая строка кода, которая появляется на образцах, процент образцов, на которых появляется строка. Это прямая мера того, что было бы спасено, если бы этой линии не было. Здесь одно обсуждение. Здесь другое, и другое. И, как сказал Пол, Zoom должен это сделать.

Если ваше время прошло от 60 секунд до 1 секунды, это означает, что каждый образец стека имел бы 59/60 вероятность показать вам проблему.

Ответ 2

Попробуйте Масштаб - Я считаю, что он позволит вам профилировать все процессы - было бы интересно узнать, подчеркивает ли это вашу проблему в этом случае.

Ответ 4

Быстро взломать тривиальный прокси-сервер для linux: http://vi-server.org/vi/simple_sampling_profiler.html

Он добавляет backtrace(3) к файлу на SIGUSR1, а затем преобразует его в аннотированный источник.

Ответ 5

Попробовав все предложенное здесь (за исключением ныне несуществующего Zoom, который по-прежнему доступен в виде огромного файла из dropbox), я обнаружил, что НИЧТО не делает то, что рекомендует мистер Данлавей. Перечисленные выше в некоторых ответах "быстрые взломы" для меня не устроили или не сработали. Потратил весь день, пытаясь что-то сделать... и ничто не могло найти fseek в качестве горячей точки в простой в другом тесте программе, которая была связана с вводом/выводом.

Поэтому я написал еще один профилировщик, на этот раз без сборочных зависимостей, основанный на GDB, поэтому он должен "просто работать" практически для любого отлаживаемого кода. Один файл CPP.

https://github.com/jasonrohrer/wallClockProfiler

Он автоматизирует ручной процесс, предложенный г-ном Данлаве, периодически прерывая целевой процесс с помощью GDB и собирая трассировку стека, а затем распечатывая в конце отчет о том, какие трассировки стека являются наиболее распространенными. Это ваши настоящие горячие точки настенных часов. И это на самом деле работает.