Linux perf: как интерпретировать и находить горячие точки

Ответ 1

Вы должны дать hotspot попробовать: https://www.kdab.com/hotspot-gui-linux-perf-profiler/

Он доступен на github: https://github.com/KDAB/hotspot

Он, например, способен создавать плагины для вас.

Ответ 2

С Linux 3.7 perf наконец-то может использовать информацию DWARF для создания callgraph:

perf record --call-graph dwarf -- yourapp
perf report -g graph --no-children

Углубленный, но графический интерфейс curses ужасен по сравнению с VTune, KCacheGrind или аналогичным... Я рекомендую попробовать FlameGraphs, что является довольно аккуратной визуализацией: http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html

Примечание. На шаге отчета -g graph результаты, полученные в результате, просты для понимания "по отношению к общим" процентам, а не по отношению к родительским. --no-children будет показывать только собственную стоимость, а не инклюзивную стоимость - функцию, которую я также считаю неоценимой.

Если у вас есть новый процессор perf и Intel, попробуйте также разматыватель LBR, который имеет гораздо лучшую производительность и создает гораздо меньшие файлы результатов:

perf record --call-graph lbr -- yourapp

Недостатком здесь является то, что глубина стека вызовов более ограничена по сравнению со стандартной конфигурацией размотки DWARF.

Ответ 3

Хорошо, эти функции могут быть медленными, но как узнать, откуда их вызывают? Поскольку все эти горячие точки лежат во внешних библиотеках, я не вижу возможности оптимизировать свой код.

Вы уверены, что ваше приложение someapp построено с опцией gcc -fno-omit-frame-pointer (и, возможно, его зависимыми библиотеками)? Что-то вроде этого:

g++ -m64 -fno-omit-frame-pointer -g main.cpp

Ответ 4

Вы можете получить очень подробный отчет об уровне источника с perf annotate, см. Анализ исходного уровня с перфомансом. Это будет выглядеть примерно так (бесстыдно украденное с сайта):

------------------------------------------------
 Percent |   Source code & Disassembly of noploop
------------------------------------------------
         :
         :
         :
         :   Disassembly of section .text:
         :
         :   08048484 <main>:
         :   #include <string.h>
         :   #include <unistd.h>
         :   #include <sys/time.h>
         :
         :   int main(int argc, char **argv)
         :   {
    0.00 :    8048484:       55                      push   %ebp
    0.00 :    8048485:       89 e5                   mov    %esp,%ebp
[...]
    0.00 :    8048530:       eb 0b                   jmp    804853d <main+0xb9>
         :                           count++;
   14.22 :    8048532:       8b 44 24 2c             mov    0x2c(%esp),%eax
    0.00 :    8048536:       83 c0 01                add    $0x1,%eax
   14.78 :    8048539:       89 44 24 2c             mov    %eax,0x2c(%esp)
         :           memcpy(&tv_end, &tv_now, sizeof(tv_now));
         :           tv_end.tv_sec += strtol(argv[1], NULL, 10);
         :           while (tv_now.tv_sec < tv_end.tv_sec ||
         :                  tv_now.tv_usec < tv_end.tv_usec) {
         :                   count = 0;
         :                   while (count < 100000000UL)
   14.78 :    804853d:       8b 44 24 2c             mov    0x2c(%esp),%eax
   56.23 :    8048541:       3d ff e0 f5 05          cmp    $0x5f5e0ff,%eax
    0.00 :    8048546:       76 ea                   jbe    8048532 <main+0xae>
[...]

Не забывайте передавать флаги -fno-omit-frame-pointer и -ggdb при компиляции кода.

Ответ 5

Если ваша программа имеет очень мало функций и вряд ли когда-либо называет системную функцию или ввод-вывод, профилировщики, которые примерят счетчик программ, не расскажут вам много, как вы обнаружите. Фактически, известный профилировщик gprof был создан специально для того, чтобы попытаться устранить бесполезность профилирования, использующего только время во времени (а не то, что это удалось).

Что на самом деле работает, это то, что отображает стек вызовов (таким образом, выясняя, откуда идут вызовы), на время настенных часов (включая время ввода/вывода) и отчитываться по строке или по инструкции (тем самым, определяя вызовы функций, которые вы должны исследовать, а не только те функции, в которых они живут).

Кроме того, статистика, которую вы должны искать, - это процент времени на стек, а не количество вызовов, а не среднее время включения. Особенно не "само время". Если команда вызова (или команда без вызова) находится в стеке 38% времени, то, если вы могли бы избавиться от нее, сколько бы вы спасли? 38% Довольно просто, нет?

Примером такого профилировщика является Zoom.

Есть больше вопросов, которые следует понимать по этому вопросу.

Добавлено: @caf заставил меня искать информацию perf, и поскольку вы включили аргумент командной строки -g, он собирает образцы стека. Затем вы можете получить отчет call-tree. Затем, если вы убедитесь, что вы пробуете время на стене (так что вы получаете время ожидания, а также время процессора), у вас есть почти то, что вам нужно.