关于gprof和gprof2dot生成的图的一些疑惑

Posted 2023-03-06

【中文标题】关于gprof和gprof2dot生成的图的一些疑惑

【英文标题】：Some doubts about the graph generated by gprof and gprof2dot

【发布时间】：2013-05-21 07:19:47

【问题描述】：

我使用 gprof2dot 生成了下面的图表，它可视化了我的程序的分析输出。

我对图表有些疑惑：

首先，为什么调用树的根不是 main()，而根 Bat_Read() 甚至没有出现在我的程序中，而是在 .h 文件中声明。

其次，GMatrix是一个没有显式析构函数的C++类，它调用图中的两个函数是不合理的。几乎一半的时间花费也是不合逻辑的。

第三，图底部的long函数是什么，花费了6.94%的时间？

您可以在新标签页中阅读图表并将其放大，以便清楚地看到它。

【参考方案1】：

我只是放大了图像以便阅读。

底部的函数很宽，只是因为它的名字非常长，但它只是一个红黑树的方法_M_Erase。它被galois_w16_region_multiply 调用了半百万次。它的大小引起了你的注意，但实际上它只出现在大约 7% 的样本上。

如果您将图表中没有父对象的每个块都取出，并将它们的百分比相加，您将得到 100%。 所有这些都表明gprof 通过调用图向上传播时间的方法是不稳定的，因此它认为事情在顶部，而实际上它只是无法确定调用者是谁。

你不能从中看出太多。你可以考虑alternatives to gprof。

添加：Gprof 将一些入口代码放入使用 -pg 标志编译的每个函数中。因此，当 A 调用 B 时，B 中的代码通过使用返回地址并在函数表中查找它来试图找出调用它的例程。它使用它来增加一个计数器，说明 A 调用 B 的次数。如果由于某种原因它无法找出正确的调用者，则会出现如图所示的错误。例如，它说例程

  ~vector
  ~GMatrix
  galois_w32_region_multby_2
  galois_get_log_table
  Bat_Read

位于调用链的顶端（您的函数中没有调用者）。 而且它认为main被Bat_Read调用了。

这是 gprof 的典型。