Это зависит от того, насколько обычным вы хотите быть.
gprof делает обе вещи, о которых вы упомянули. Вот несколько комментариев по этому поводу.
Существует школа мысли, которая говорит, что профилирование — это измерение. Измерение чего? Ну что угодно - только мерить. Наряду с этим возникает идея, что вы хотите получить «общую картину» того, что происходит. Эта школа в основном рассматривает попытки найти «медленные функции», не определяя четко, что это вообще означает, и не предлагая вам искать там для оптимизации.
Другая школа говорит, что вы действительно отлаживаете. Вы хотите точно определить местонахождение ошибок определенного типа — таких, которые не делают программу неправильной, а занимают слишком много времени. Это не масштабные вещи. Это очень точные точки в коде, где происходит что-то, что требует гораздо больше времени, чем необходимо. На сколько больше - не важно. Важно то, что он расположен так, чтобы его можно было зафиксировать. С этой точки зрения накладные расходы на профилирование не имеют значения, равно как и точность измерения. Измерение предназначено для того, чтобы увидеть, сколько времени было сэкономлено.
Одним из профилировщиков, который, как мне кажется, успешно охватывает оба лагеря, является Zoom, поскольку он производит выборку стека вызовов на время настенных часов и представляет на уровне строки/инструкции процент времени в стеке. Некоторые другие профилировщики также делают это, но большинство этого не делает.
Я учусь во второй школе, и вот пример того, что вы можете сделать с ним.
Вот более кратко обсуждение вопросов.
person
Mike Dunlavey
schedule
12.01.2011
