我建议打印一份gprof 论文并仔细阅读。
根据论文，这是 gprof 测量时间的方式。它对 PC 进行采样，并计算每个例程中有多少样本落入。乘以样本之间的时间，即每个例程的总自身时间。
它还在一个表中按调用站点记录例程 A 调用例程 B 的次数，假设例程 B 由-pg选项检测。通过总结这些，它可以知道例程 B 被调用了多少次。
从调用树的底部开始（其中总时间 = 自身时间），它假设每个例程每次调用的平均时间是其总时间除以调用次数。
然后它会返回到这些例程的每个调用者。每个例程的时间是其平均自身时间加上对每个从属例程的平均调用次数乘以从属例程的平均时间。
您可以看到，即使不存在递归（调用图中的循环），这也充满了错误的可能性，例如关于平均时间和平均调用次数的假设，以及关于被检测的子程序的假设，作者指出出去。如果有递归，他们基本上会说“忘记它”。
所有这些技术，即使没有问题，也引出了一个问题——它的目的是什么？通常，目的是“找到瓶颈”。根据该论文，它可以帮助人们评估替代实现。那不是发现瓶颈。他们确实建议查看似乎被多次调用或平均调用次数较高的例程。当然，平均累积时间低的例程应该被忽略，但这并不能很好地定位问题。而且，它完全忽略了 I/O，就好像所有完成的 I/O 毫无疑问都是必要的。
因此，要尝试回答您的问题，请尝试Zoom，不要期望消除测量中的统计噪声。
gprof 是一个古老的工具，简单而坚固，但它最初存在的问题仍然存在，并且在随后的几十年中出现了更好的工具。 这是问题清单。
gprof 不是很准确，特别是对于小函数，见http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC11
如果这是 Linux，那么我推荐一个不需要检测代码的分析器，例如Zoom——您可以获得 30 天免费评估许可证，之后需要付费。
所有采样分析器都存在统计不准确的问题——如果误差太大，那么您需要更长的采样时间和/或更小的采样间隔。