我正在尝试使用gprof对c++函数进行分析,我是在所花费的%时间内进行分析的。我跑了不止一次,由于某种原因,结果有很大的不同。我不知道造成这种情况的原因,我假设抽样率,或者我在其他文章中看到I/O与此有关。那么,是否有一种方法可以使它更加精确,并以某种方式产生几乎恒定的结果?
我在想以下几点:
等待你的意见
问候
发布于 2011-02-17 13:58:26
我建议打印一份gprof纸并仔细阅读。
根据这篇论文,这是gprof如何测量时间的。它对PC进行采样,并计算每个例程中有多少个样本。乘以样本之间的时间,即每个例程的总自我时间。
它还通过调用站点在表中记录例程A调用例程B的次数,假设例程B是由-pg选项检测的。通过总结这些,它可以判断出调用例程B的次数。
从调用树的底部开始(其中总时间= self时间),它假设每个例程的平均每次调用时间是它的总时间除以调用的次数。
然后,它会返回到这些例程的每个调用者。每个例程的时间是它的平均自我时间加上对每个从属例程调用的平均次数乘以从属例程的平均时间。
您可以看到,即使没有递归(调用图中的循环),这是如何充满了错误的可能性,例如假设的平均次数和平均调用数,以及假设的子例程被检测,作者指出。如果有递归,他们基本上会说“忘了它”。
所有这些技术,即使没有问题,也回避了一个问题--它的目的是什么?通常情况下,目的是“寻找瓶颈”。根据这篇论文,它可以帮助人们评估替代的实现。这并不能找到瓶颈。他们确实推荐去看那些看似被称为很多次的例行公事,或者是那些平均次数较高的例程。当然,低平均累积时间的例程应该被忽略,但这并不能很好地本地化问题。而且,它完全忽略了I/O,好像所有的I/O操作无疑是必要的。
因此,要想回答你的问题,就试一下缩放,不要期望消除测量中的统计噪音。
gprof是一个古老的工具,简单而坚固,但它在开始时的问题仍然存在,而且在其间的几十年里出现了更好的工具。这是一份问题清单。
发布于 2011-02-17 11:24:20
gprof不是很精确,特别是对于小型函数,请参见http://www.cs.utah.edu/dept/old/texinfo/as/gprof.html#SEC11。
如果这是Linux,那么我推荐一个不需要对代码进行检测的分析器,例如缩放 --您可以获得一个免费的30天评估许可证,在那之后它会花费很多钱。
所有抽样分析器都存在统计误差--如果误差太大,则需要采样时间更长和/或采样间隔更小。
https://stackoverflow.com/questions/5028198
复制相似问题