首先，我很惊讶这是新闻。其次，问题不在于探查器是坏的，而是某些探查器是坏的。作者认为，这只是通过避免在评估的错误中发现的一些错误，才建立了一个不错的错误。由于存在一些有关性能分析的长期存在的误解，因此经常会犯错误。

但是，让我们保持乐观。如果想找到加速的机会，那真的很简单：

采样应与程序状态无关。
这意味着在真正随机的时间发生，而不管程序是在I / O中（用户输入除外），GC中还是在紧密的CPU循环中，等等。

采样应读取函数调用堆栈，
以便确定采样时哪些语句是“活动的”。原因是每个调用站点（调用函数的点）的成本百分比等于其在堆栈上的时间的一部分。（注意：本文完全涉及自时，忽略了大型软件中可避免的函数调用的巨大影响。实际上，其背后的原因gprof是为了帮助找到这些调用。）

报告应按行显示百分比（而不按功能显示）。
如果识别出“热”功能，则仍然需要在其中寻找占时间的“热”代码行。这些信息在样本中！为什么隐藏它？

一个几乎普遍的错误（论文共有）是过多地关注测量精度，而不是位置精度。例如，这是一个性能调整的示例， 其中发现并解决了一系列性能问题，从而使复合速度提高了43倍。不必在解决每个问题之前准确知道每个问题的大小，但要知道其位置。性能调整的现象是，通过减少时间来解决一个问题，会放大剩余问题的百分比，因此更容易找到它们。只要有发现并解决问题，朝着发现并解决所有问题的目标取得进展。以减小的大小顺序固定它们不是必不可少的，但是精确定位它们是必不可少的。

关于测量的统计准确性，如果调用点在堆栈上，则抽取一定百分比的时间F（例如20％）和N（例如100）随机时间样本，则显示该呼叫的样本数点是二项分布，平均值= NF = 20，标准偏差= sqrt（NF（1-F））= sqrt（16）=4。因此，显示该百分比的样本百分比将为20％+/- 4％ 。这样准确吗？不是真的，但是找到问题了吗？精确地

实际上，就百分比而言，问题越大，找到它所需的样本就越少。例如，如果采样了3个样本，并且其中有2个出现了呼叫点，则很可能会非常昂贵。（具体来说，它遵循beta分布。如果生成4个统一的0,1随机数，然后对它们进行排序，则第3个分布是该呼叫点的成本分布。其平均值是（2 + 1）/（ 3 + 2）= 0.6，所以给定这些样本，这就是预期的节省。）插入：而且，您得到的加速因子由另一个分布BetaPrime控制，其平均值为4。因此，如果您进行3个采样，请参见其中两个问题，并消除该问题，平均而言，您可使程序运行速度提高四倍。

现在是时候让我们的程序员在剖析主题上把蜘蛛网从头脑中吹灭了。

免责声明-该论文未能引用我的文章：Dunlavey，“从调用堆栈采样中得出的指令级成本进行性能调优”，ACM SIGPLAN Notices 42，8（2007年8月），第4-8页。