我试图使用gprof来描述一个c函数,我对％的时间感兴趣.我做了不止一次跑步,由于某种原因,我在结果上有很大差异.我不知道是什么导致这种情况,我假设采样率或我在其他帖子中读到I / O与它有关.那么有没有办法让它更准确并以某种方式产生几乎恒定的结果？

我在考虑以下几点：

>提高采样率
>在执行任何操作之前刷新缓存
>使用另一个探查器,但我希望它以与函数时间％函数名称相似的格式生成结果,我尝试了Valgrind,但它给了我一个大小的文件.所以也许我用错误的命令生成文件.

等待你的意见

问候

解决方法:

我建议打印一份the gprof paper并仔细阅读.

根据该论文,这里是gprof如何衡量时间.它对PC进行采样,并计算每个例程中有多少样本着陆.乘以样本之间的时间,即每个例程的总自我时间.

它还通过调用站点在表中记录例程A调用例程B的次数,假设例程B由-pg选项进行检测.通过总结它们,它可以告诉我们调用常规B的次数.

从呼叫树的底部开始(其中总时间=自身时间),它假设每个例程的每次呼叫的平均时间是其总时间除以呼叫数.

然后它会回复到这些例程的每个调用者.每个例程的时间是它的平均自我时间加上每个从属例程的平均调用次数乘以从属例程的平均时间.

你可以看到,即使递归(调用图中的周期)不存在,如何充满错​​误的可能性,例如关于平均时间和平均调用次数的假设,以及关于被检测的子程序的假设,作者指出出.如果有递归,他们基本上会说“忘了”.

所有这些技术,即使它没有问题,也引出了一个问题 – 它的目的是什么？通常,目的是“找到瓶颈”.根据该论文,它可以帮助人们评估替代实施.那不是瓶颈.他们建议查看似乎被称为很多次或平均时间较长的例程.当然应该忽略平均累积时间较短的例程,但这不会非常本地化问题.并且,它完全忽略了I / O,就好像所有完成的I / O无疑是必要的.

因此,要尝试回答您的问题,请尝试使用Zoom,并且不要期望消除测量中的统计噪声.

gprof是一种古老的工具,简单而坚固,但它在一开始就存在的问题仍然存在,并且在过去的几十年中出现了更好的工具.
Here’s a list of the issues.