java - 如果 profiler 不是答案，我们还有什么其他选择？

Question

看了Joshua Bloch 的“Performance Anxiety”演讲后，我阅读了他在演讲中建议的论文"Evaluating the Accuracy of Java Profilers" .引用结论:

Our results are disturbing because they indicate that profiler incorrectness is pervasive—occurring in most of our seven benchmarks and in two production JVM—-and significant—all four of the state-of-the-art profilers produce incorrect profiles. Incorrect profiles can easily cause a performance analyst to spend time optimizing cold methods that will have minimal effect on performance. We show that a proof-of-concept profiler that does not use yield points for sampling does not suffer from the above problems

论文的结论是，我们不能真正相信分析器的结果。但是，使用分析器的替代方法是什么。我们是不是应该回去只凭感觉做优化？

更新:讨论中似乎遗漏的一点是观察者效应。我们能否构建一个真正无“观察者效应”的分析器？

Answer 1

哦，伙计，从哪里开始？

首先，我很惊讶这是新闻。其次，问题不在于分析器不好，而在于 一些 分析器不好。 作者构建了一个他们认为很好的模型，只是避免了他们在评估的错误中发现的一些错误。 错误很常见，因为一些持久的myths about performance profiling .

但让我们保持积极的态度。 如果想找到加速的机会，其实很简单:

• 采样应该与程序的状态不相关。
  这意味着发生在真正随机的时间，无论程序是在 I/O(用户输入除外)还是在 GC 中，还是在紧密的 CPU 循环中，或者其他什么。

• 采样应该读取函数调用栈,
  以确定哪些语句在采样时是“活跃的”。 原因是每个调用站点(调用函数的点)的百分比成本等于它在堆栈上的时间分数。 (注意:本文完全关注自时间，忽略了大型软件中可避免的函数调用的巨大影响。事实上，最初的 gprof 背后的原因是为了帮助找到这些调用。)

• 报告应按行显示百分比(而不是按功能)。
  如果识别出一个“热”函数，仍然需要在其中寻找占时间的“热”代码行。该信息在样本中!为什么要隐藏它？

一个几乎普遍的错误(该论文共享)是过于关注测量的准确性，而对位置的准确性却不够关注。 例如，这里是 example of performance tuning 其中发现并修复了一系列性能问题，实现了 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 个样本，在其中 2 个样本上发现问题，然后消除该问题，平均而言，您将使程序快四倍。

现在是时候让我们的程序员在剖析问题上大惊小怪了。

免责声明 - 论文未能引用我的文章:Dunlavey，“Performance tune with instruction-level cost derived from call-stack sampling”，ACM SIGPLAN Notices 42, 8(2007 年 8 月)，第 4-8 页。