Профилировщик на основе временных примеров Linux

Question

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

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

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

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

Проблема заключалась в том, что в цикле создавался фильтр на C ++, чтобы разобрать имя на C ++. Я только случайно наткнулся на код, когда преследовал другое узкое место. OProfile не показывал ничего необычного в коде, поэтому я почти проигнорировал его, но мой смысл кода подсказал мне оптимизировать вызов и посмотреть, что произошло. Я изменил popen с ++ фильтра на abi::__cxa_demangle. Время выполнения увеличилось с более минуты до чуть более секунды. Примерно в 60 раз быстрее.

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

Вот моя конфигурация 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 записывает только свои образцы в текущий запущенный процесс. Я бы хотел, чтобы он всегда регистрировал свои образцы в процессе, который я профилирую. Поэтому, если процесс в данный момент отключен (блокировка ввода-вывода или вызов popen), OProfile просто поместит свою выборку в заблокированный вызов.

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

Answer 1

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

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

Answer 2

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

Answer 3

Я написал это давным-давно, только потому, что не смог найти ничего лучшего: https://github.com/dicej/profile

Я тоже нашел это, хотя и не пробовал: https://github.com/oliver/ptrace-sampler

Answer 4

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

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

Answer 5

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

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

https://github.com/jasonrohrer/wallClockProfiler

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