如何以图形方式可视化配置文件？答案

【问题标题】：How to visualize profile files graphically?如何以图形方式可视化配置文件？
【发布时间】：2014-01-03 04:13:47
【问题描述】：

我正在 Windows 8.1 64 位上开发 Go 1.2。我在让 go pprof 工具正常工作时遇到了很多问题，例如显示内存地址而不是实际的函数名称。

但是，我发现profile 似乎在生成配置文件方面做得很好，可以与 pprof 工具一起使用。我的客人是，我如何使用这些配置文件进行图形可视化？

【问题讨论】：

标签： go profiling

【解决方案1】：

你可以试试go tool pprof /path/to/program profile.prof来解决function not true问题。

如果您想要图形可视化，请尝试在 pprof 中输入web。

【讨论】：

【解决方案2】：

如果您的目标是看到漂亮但基本上毫无意义的图片，请按照@Specode 的建议进行可视化。

如果您的目标是速度，那么我建议您忘记可视化。可视化不会告诉您需要修复什么。

This method does tell you what to fix. 您可以在 GDB 中非常有效地做到这一点。

编辑以回应@BurntSushi5：

这是我对图表的抱怨：)

首先，它们非常容易被愚弄。例如，假设 A1 将所有时间都花在调用 C2 上，反之亦然。然后假设插入了一个新的例程B，这样当A1调用B时，B调用C2，当A2调用B时，B调用C1。该图丢失每次调用 C2 时，A1 在堆栈上位于它之上的信息，反之亦然。

再举一个例子，假设每次调用 C 都来自 A。然后假设 A “调度”到一堆函数 B1，B2，...，每个函数都调用 C。图丢失了每次调用 C 都来自 A 的信息。

现在到链接的图表：

它非常强调自我时间，制作巨型盒子，而包容性时间更为重要。（事实上，发明gprof 的全部原因是因为自拍时间与只有秒针的时钟一样有用。）他们至少可以按包含时间来缩放盒子。
它没有说明调用来自的代码行，或者花费自己时间的代码行。它基于所有功能都应该很小的假设。也许这是真的，也许不是，但这是否足以成为配置文件输出无用的充分理由？
里面塞满了无关紧要的小盒子，因为它们的时间微不足道。他们所做的只是占用大量房地产并分散您的注意力。
里面没有关于 I/O 的内容。图表来自的分析器显然体现了唯一的 I/O 是必要的 I/O，因此没有必要对其进行分析（即使需要 90% 的时间）。在大型程序中，很容易完成不必要的 I/O，花费大量时间，而所谓的“CPU 分析器”有偏见，认为它甚至不存在。
该图中似乎没有任何递归实例，但递归是常见且有用的，并且图很难通过有意义的度量来显示它。

只是指出，如果取少量堆栈样本，大约一半会是这样的：

blah-blah-couldn't-read-it
blah-blah-couldn't-read-it
blah-blah-couldn't-read-it
fragbag.(*structureAtoms).BestStructureFragment
structure.RMSDMem
... a couple other routines

另一半样本正在做其他事情，同样提供信息。由于每个堆栈示例都向您展示了调用来自的代码行，因此您实际上被告知了为什么要花费这些时间。（不需要花费太多时间的活动被抽样的可能性很小，这很好，因为你不关心这些。）

现在我不知道这段代码，但图表让我强烈怀疑，就像我看到的很多代码一样，数据结构中有魔鬼。

【讨论】：

我已经多次使用与 Go 工具捆绑的分析器来成功优化我的程序。这包括使用分析器可以生成的“无意义”调用图。
@BurntSushi5：a) 你的程序是大还是小？探查器在小程序上工作得很好。 b) 你得到了多少加速？人们对小小的加速感到满意——他们认为这就是全部。 Here's an example of 730x.Here's one of those meaningful graphs.
广泛的程序。有些小有些大。
另外，该图看起来不是很有用。百分比都是100%！这是我使用的那种图表，它是从 Go 工具链生成的：burntsushi.net/stuff/flib-prof.jpg 我不会跟踪我获得的每一次加速，但我经常编写可能需要几天才能运行的幼稚代码。在分析器的帮助下，我有时设法将其缩短到几小时或几分钟。（这通常是更智能地分配的问题，而分析器在这方面有很大帮助。）
请注意，我并没有声称我的方法更好。我只是声称这些图表是有意义的，我的证据是我已经使用它们来调整我的程序以达到很好的效果。