【发布时间】：2009-11-20 15:58:00
【问题描述】：
在某种程度上与this question 相关，您会推荐哪种工具来评估使用 callgrind 创建的分析数据？
它不必有图形界面，但它应该以简洁、清晰和易于解释的方式准备结果。我知道例如kcachegrind，但是这个程序缺少一些功能，例如显示的表格的数据导出或简单地从显示中复制行。
【问题讨论】：
标签： profiling evaluation callgrind
【发布时间】：2009-11-20 15:58:00
【问题描述】：
几年前，我编写了一个在 DOS 下运行的分析器。
如果您使用的是 KCacheGrind，我会这样做。写起来可能不会太难，或者你可以用手来做。
KCacheGrind 有一个工具栏按钮“强制转储”，您可以使用它在随机时间手动触发转储。在等待程序的时间间隔内随机或伪随机时间捕获堆栈跟踪是该技术的核心。
需要的样本并不多 - 通常 20 个就足够了。如果一个瓶颈成本很高，比如超过 50%，5 个样本可能就足够了。
样本的处理非常简单。每个堆栈跟踪都由一系列代码行（实际上是地址）组成，其中除了最后一行之外都是函数/方法调用。
收集示例中出现的所有代码行的列表，并消除重复。
对于每一行代码，计算它出现在样本中的比例。例如，如果您抽取 20 个样本，并且代码行出现在其中 3 个样本上，即使它在某个样本中出现多次（由于递归），计数也是 3/20 或 15%。这是对每个语句成本的直接衡量。
显示成本最高的 100 行左右的代码。您的瓶颈在该列表中。
我通常用这些信息做的事情是选择一条成本很高的线路，然后手动采集堆栈样本直到它出现（或查看我已经得到的那些），然后问自己“为什么要这样做代码，不仅在本地意义上，而且在全球意义上。”另一种说法是“在全局意义上，程序试图在采样时完成的时间片”。我问这个的原因是因为这告诉我是否真的有必要花费这条线的成本。
我不想批评人们开发分析器所做的所有伟大工作，但遗憾的是，关于这个主题有很多根深蒂固的神话，包括：
使用大量样品进行精确测量很重要。相反，重点应该是发现瓶颈。精确测量不是这样做的先决条件。对于成本在 10% 到 90% 之间的典型瓶颈，测量可能非常粗略。
函数比代码行更重要。如果你找到一个代价高昂的函数，你仍然需要在其中搜索成为瓶颈的行。该信息就在堆栈跟踪中 - 无需寻找它。
您需要区分 CPU 和挂钟时间。如果你在等它，那就是挂钟时间（手表时间？）。例如，如果您有一个由无关 I/O 组成的瓶颈，您是否想忽略它，因为它不是 CPU 时间？
区分独占时间和包含时间是有用的。仅当您正在计时功能并且您想知道时间是否花在被调用者上时才有意义。如果您查看代码行，唯一重要的是包含时间。另一种说法是，每条指令都是调用指令，即使它只调用微码。
递归很重要。这无关紧要，因为它不影响线路所在的样本分数，因此是负责的。
行或函数的调用计数很重要。无论是快速但被调用太多次，还是缓慢而被调用一次，成本都是它使用的时间百分比，这就是堆栈样本的估计值。
采样的性能很重要。我不介意获取堆栈样本并在继续之前查看几分钟，假设这不会使瓶颈移动。
Here's更完整的解释。
【讨论】：
有一些 CLI 工具可用于处理 callgrind 数据：
callgrind_annotate
和 cachegrind 工具，可以显示 callgrind.out 中的一些信息
cg_annotate
【讨论】：