В ответ на ответ @ Charlie вы говорите, что в идеале вам нужна информация о как программа тратит свое время.
Есть и другая точка зрения - вам нужно знать , почему программа тратит свое время.
Причина, по которой каждый цикл тратится, - это цепочка причин, где каждая ссылка представляет собой строку кода в стеке вызовов. Цепь не сильнее, чем ее самое слабое звено.
Если программа не работает настолько быстро, насколько это возможно, у вас есть "узкие места".
Например, если «узкое место» тратит впустую 20% времени, то оно состоит из оптимизируемой строки кода (то есть плохо обосновано), которая находится в стеке 20% времени. Все, что вам нужно сделать, это найти его.
Если будет взято 10000 образцов стека, это будет около 2000 из них. Если будет взято 10 образцов, то в среднем будет 2 из них.
На самом деле, если вы случайно приостановите программу несколько раз и изучите стек вызовов, если вы увидите оптимизируемую строку кода всего в 2 выборках , вы обнаружите «узкое место».
Вы можете исправить это, получить хорошее ускорение и повторить весь процесс.
Это основа этой техники .
Несмотря на это, размышления в терминах gprof концепций не будут вам полезны.