为什么gprof明显低估了程序的运行时间？
我有这个程序需要2.34秒才能运行，gprof表示它只需要1.18秒。 我已经读过其他地方的答案，建议如果例如程序受I / O限制，gprof可能会出错，但这个程序显然不是。
这也适用于我试图描述的有用程序。 这不是特定于这个琐碎的测试用例。
（同样在这种情况下，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. 我建议删除gprof并切换到oprofile 。 将检测插入程序的任何分析都会以可能使结果偏斜或无效的方式固有地影响性能。 使用oprofile您不必使用分析支持来构建程序，也不必使用特殊的分析启用库; 它通过统计方法工作，基本上对指令指针进行采样（使用内核辅助）并使用样本计数来估计每个函数花费了多少时间。
首先，为了回答你的问题， gprof没有计算阻塞时间，所以如果机器上的任何其他东西“同时”发生，你会看到这种差异。 此外，如果您的程序执行任何I / O，也不会计算。
gprof实际上只对非常有限的程序类有用。 这是一个问题列表。
首先，分析一个在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％数字。
这是一个统计过程，并不完美。 你必须用一粒盐来解释结果。
祝好运！