Неточность в выводе gprof - PullRequest
2 голосов
/ 17 февраля 2011

Я пытаюсь профилировать функцию c ++ с помощью gprof, меня интересует, сколько времени заняло.Я сделал больше одного пробега и по какой-то причине получил большую разницу в результатах.Я не знаю, что является причиной этого, я предполагаю частоту дискретизации или читаю в других постах, что ввод / вывод как-то связан с этим.Так есть ли способ сделать его более точным и получить почти постоянные результаты?

Я думал о следующем:

  1. увеличить частоту дискретизации
  2. очистить кеш перед выполнением чего-либо
  3. использовать другой профилировщик, но я хочучтобы генерировать результаты в формате, похожем на grof, как время функции% имя функции, я попробовал Valgrind, но он дал мне огромный размер файла.Поэтому, возможно, я генерирую файл с неверной командой.

Ожидание вашего ввода

С уважением

Ответы [ 2 ]

4 голосов
/ 17 февраля 2011

Я рекомендую распечатать копию бумаги gprof и внимательно ее прочитать.

Согласно бумаге, вот как gprof измеряет время.Он сэмплирует ПК и подсчитывает, сколько сэмплов попадает в каждую процедуру.Умножается на время между выборками, то есть общее время каждой процедуры self time .

. Кроме того, в таблице по месту вызова записывается, сколько раз процедура A вызывает процедуру B, принимая процедуру Bинструментируется параметром -pg .Суммируя их, он может сказать, сколько раз была вызвана подпрограмма B.

Начиная с нижней части дерева вызовов (где общее время = собственное время), предполагается, что среднее время на вызов каждой подпрограммы равноего общее время делится на количество вызовов.

Затем выполняется обратная связь для каждого абонента этих подпрограмм.Время каждой подпрограммы - это среднее собственное время плюс среднее количество вызовов каждой подчиненной подпрограммы, умноженное на среднее время подчиненной подпрограммы.

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

Вся эта технология, даже если она не была проблематичной, заставляет задуматься: какова ее цель?Обычно целью является «найти узкие места».Согласно документу, он может помочь людям оценить альтернативные реализации.Это не найти узких мест.Они рекомендуют смотреть на подпрограммы, которые, кажется, вызываются много раз или имеют высокое среднее время.Конечно, подпрограммы с низким средним суммарным временем следует игнорировать, но это не сильно локализует проблему.И он полностью игнорирует ввод-вывод, как если бы все выполняемые операции ввода-вывода безусловно необходимы.

Итак, чтобы попытаться ответить на ваш вопрос, попробуйте Zoom , например, ине ожидайте устранения статистического шума при измерениях.

gprof - почтенный инструмент, простой и надежный, но проблемы, с которыми он сталкивался в начале, все еще существуют, и за прошедшие десятилетия появились гораздо лучшие инструменты., Вот список вопросов.

2 голосов
/ 17 февраля 2011

gprof не очень точный, особенно для небольших функций, см. http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC11

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

Все профилировщики выборки страдают от статистических погрешностей - если ошибка слишком велика, вам нужно проводить выборку дольше и / или с меньшим интервалом выборки.

...