Что такое хороший простой в использовании профилировщик для C ++ в Linux? [закрыто]


79

Мне нужно профилировать код, работающий на C ++ в Linux. Ребята, вы можете порекомендовать профайлеров?


1
Вы должны добавить теги Linux и C ++. Вы, вероятно, получите лучший ответ и разнообразие мнений.
Duck

2
Похоже на дубликат stackoverflow.com/questions/375913/… .
Майкл Майерс

например: likwid, LLTng, oprofile, valgrind, vtune, gprof, perf, gperftools, pTop
Шан

См. Этот вопрос на сайте slant
ideasman42

Ответы:


37

Используйте gprof.

Просто скомпилируйте с -pgфлагом (я думаю (но не уверен), что вам нужно отключить оптимизацию.) И используйте gprof для анализа файла gmon.out, который затем создаст ваш исполняемый файл.

например:

gcc -pg -o whatever whatever.c

./whatever

gprof whatever gmon.out

То же самое с g ++ и cpp.


32
Профилирование неоптимизированного кода немного бессмысленно, не правда ли? Точно так же код профилирования, который был сильно изменен с помощью -pg, часто вводит вас в заблуждение, оптимизируя неправильные места.
федеральный

1
-pg - вариант компоновщика, а не компилятор
Slug Pue

24

valgrind - хорошо известный профилировщик Linux


подумал, что valgrind был больше для проверки на утечку памяти .. Я пытаюсь увидеть, какие функции вызываются и т. д.
Шергилл

14
используйте инструмент набора под названием "callgrind"
dfa

2
Valgrind - это просто платформа для создания динамических инструментов. Хотя это стало синонимом Memcheck, инструмента, построенного на Valgrind. Callgrind неплохо умеет профилировать.
Falaina


13

Zoom from RotateRight ( http://www.rotateright.com ) - это то, что я использовал. Он имеет вид бабочек функций, и вы можете дважды щелкнуть любую функцию, чтобы погрузиться в исходный или asm-код. Выполните сборку с отладочной информацией (-g), чтобы увидеть исходный код, но вы все равно должны создавать и профилировать оптимизированный код.


1
Просто попробовал эту программу, это действительно здорово! В настоящее время мой любимый профилировщик в Linux; однако стоит упомянуть, что -fno-omit-frame-pointerдля эффективного профилирования требуется создание кода .
Ник Рейман,

1
Ссылка кажется мертвой. Кто-нибудь знает, где (или если) его можно найти в другом месте?
Simon F

12

Я фанат Oprofile . Он включает в себя установку модуля ядра и требует некоторого обучения, но он довольно мощный и очень хорошо работает для оптимизированных программ / программ без символов отладки.

Vtune - еще один очень мощный профилировщик от Intel. Я считаю, что версия для Linux бесплатна для некоммерческого программного обеспечения.

Существует также набор инструментов Valgrind , предложенный dfa. Callgrind, вероятно, будет тем, что вас больше всего интересует. Cachegrind (набор функций которого является подмножеством Callgrind) и Massif также интересны, но у меня нет опыта работы с последними.


+1 для oprofile, это не «легкий инструмент»
dfa

1
Ха-ха, правда. Я, наверное, не должен делать это так просто :) Это, конечно, не так просто, как «запускать программу под ним», как инструменты Vtune и Valgrind, но я чувствую, что вы довольно быстро к этому привыкаете.
Falaina

oprofile выглядит интересно - поддерживает ли он x86_64?
LiraNuna

К сожалению, VTune не бесплатен ни для каких целей.
rustyx



2

gprof - это стандартный инструмент GNU для профилирования.


2

Взгляните на Sysprof . Скорее всего, в вашем дистрибутиве он уже есть.

Обратите внимание, что все упомянутые профилировщики работают лучше всего, если ваше приложение скомпилировано с указателями кадров. То есть вы должны использовать -fno-omit-frame-pointer в командной строке gcc.


1

вы просто основываете свое суждение об узком месте на 10 образцах, собранных вами вручную, вместо 1000 образцов, собранных вами prof.
Дмитрий Григорьев

1
@DmitryGrigoryev: Верно, и это фактически говорит вам, что вам следует исправить. Статистическое объяснение здесь . Фактически, первая ошибка, которую делают люди, - это думать, что они ищут «узкое место», а не совершенно хороший, но расточительный код ;-)
Майк Данлэви,

Приятно читать, спасибо. Я полностью согласен с вашей точкой зрения, что оптимизировать намного проще, когда вы видите реальный вызов функции в отладчике. И я понимаю, что «узкое место» не означает «хорошую цель оптимизации», а только потенциальную. Тем не менее, я думаю, что в profлюбом случае имеет смысл начать : если я увижу, что f()это наиболее проблемная функция статистически, я остановлю программу несколько раз, пока не займусь ею, f()вместо того, чтобы просто начать со случайной функции, на которой я остановился первой.
Дмитрий Григорьев
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.