Question

我有这个程序需要2.34秒才能运行，而gprof说它只需要1.18秒。我在其他地方读过的答案表明gprof可能会错误，例如程序是I / O绑定的，但这个程序显然不是。

这也适用于我正在尝试分析的有用程序。这不是特定于这个微不足道的测试用例。

（同样在这种情况下，gprof表示main（）占用了程序运行时间的100％以上，这是一个非常愚蠢的错误但不会给我带来麻烦。）

$ cat test.c
int main() {
    int i;
    for (i=0;i<1000000000;i++);
}

$ gcc test.c -o test

$ time ./test

real    0m2.342s
user    0m2.340s
sys 0m0.000s

$ gcc test.c -o test -pg

$ time ./test

real    0m2.342s
user    0m2.340s
sys 0m0.000s

$ gprof test |head
Flat profile:

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
101.33      1.18     1.18                             main

 %         the percentage of the total running time of the
time       program used by this function.

Answer 1

我建议删除gprof并切换到oprofile。将检测插入程序的任何分析都会以可能使结果偏斜或无效的方式固有地影响性能。使用oprofile，您不必使用分析支持来构建程序，也不必使用特殊的分析启用库;它通过统计方法工作，基本上对指令指针进行采样（使用内核辅助）并使用样本计数来估计每个函数花费的时间。

Answer 2

首先，要回答您的问题，gprof不会计算阻止时间，因此如果机器中的任何其他内容“同时”发生，您将看到这种差异。此外，如果您的程序执行任何I / O，也不会计算。

gprof实际上只对非常有限的一类程序有用。 Here is a list of the issues.

Answer 3

首先，分析一个在2.3秒内完成的程序是有点荒谬的。你真的需要一个长期运行的程序来测量程序热点等等。但是我离题了......

要回答您的第一个问题，时间（命令行实用程序）会占用整个过程的执行时间（包括分析工具本身）。在构建中启用分析时，程序会在每次运行程序时写入包含执行时间等的gmon.out文件。也就是说，每次运行程序时都会进行分析的艰苦工作。分析工具试图将其自身对时间会计的影响分开，在这种情况下，分析本身似乎占运行时的2.34 - 1.18 = 1.16（按时间报告）。 gprof程序本身只是分析和重新格式化存储在gmon.out程序中的运行时统计信息。要清楚这一点，真正的分析在程序运行期间发生，而不是在gprof运行期间。

最后，gprof输出直接回答你的第二个问题。它以1/100秒的速度对程序的执行进行采样。在样本期间发生的任何事情都会产生0.01秒的时间间隔。如果您的程序没有花费0.01秒的精确倍数来执行，那么您将得到的数字不会达到100％。同样，必须强调的是，对快速运行此程序的程序进行概要分析是非常容易出错的，并且这种明显的错误肯定会通过较长的采样间隔（即运行时间）来减轻。此外，gprof对其自身管理费用的核算是不完善的，这可能进一步导致看似荒谬的101.33％数字。

这是一个统计过程，并不完美。你必须用一粒盐解释结果。

祝你好运！

为什么gprof明显低估了程序的运行时间？

3 个答案: