Syn*_*ror 2 c++ profiling gprof
我正在尝试使用 gprof 分析 C++ 函数，我对所花费的 %时间感兴趣。我跑了不止一次，由于某种原因，结果有很大差异。我不知道是什么原因造成的，我假设采样率或者我在其他帖子中读到 I/O 与此有关。那么有没有一种方法可以使其更加准确并以某种方式产生几乎恒定的结果呢？
我在想以下几点：
等待您的输入
问候
我建议打印一份gprof 论文并仔细阅读。
根据该论文，gprof 测量时间的方式如下。它对 PC 进行采样，并计算每个例程中有多少个样本。乘以样本之间的时间，即为每个例程的总自我时间。
它还按调用站点在表中记录例程 A 调用例程 B 的次数（假定例程 B 通过-pg选项进行检测）。通过对这些进行总结，它可以得知例程 B 被调用了多少次。
从调用树的底部开始（其中总时间=自身时间），它假设每个例程每次调用的平均时间是其总时间除以调用次数。
然后它会返回给这些例程的每个调用者。每个例程的时间是其平均自身时间加上每个从属例程的平均调用次数乘以从属例程的平均时间。
您可以看到，即使不存在递归（调用图中的循环），这也充满了错误的可能性，例如关于平均时间和平均调用次数的假设，以及关于正在检测的子例程的假设，作者指出出去。如果有递归，他们基本上会说“算了”。
所有这些技术，即使没有问题，也会引发一个问题：它的目的是什么？通常，目的是“找到瓶颈”。根据该论文，它可以帮助人们评估替代实现。这并不是寻找瓶颈。他们确实建议查看似乎被调用很多次或平均时间较高的例程。当然，平均累积时间较低的例程应该被忽略，但这并不能很好地定位问题。而且，它完全忽略 I/O，就好像完成的所有 I/O 都是毫无疑问必要的。
因此，要尝试回答您的问题，请尝试Zoom之一，并且不要指望消除测量中的统计噪声。
gprof 是一个古老的工具，简单而坚固，但它一开始遇到的问题仍然存在，并且在接下来的几十年里出现了更好的工具。 这是问题列表。