在观看了Joshua Bloch的演讲“性能焦虑”之后，我读了他在演讲“评估Java Profilers的准确性”中建议的论文。引用结论：
我们的结果令人不安，因为它们表明分析器错误无处不在 - 在我们的七个基准测试和两个生产JVM中的大多数中都发生 - 并且重要的是 - 所有四个最先进的分析器都产生了不正确的配置文件。不正确的配置文件很容易导致性能分析师花时间优化冷方法，这些方法对性能的影响最小。我们表明，不使用屈服点进行采样的概念验证分析器不会遇到上述问题
这篇论文的结论是，我们不能真正相信分析器的结果。但是，使用探查器的替代方法是什么。我们是否应该回过头来，只是用我们的感觉来做优化？
更新：讨论中似乎遗漏的一点是观察者效应。我们能建立一个真正没有“观察者效应”的分析器吗？
哦，伙计，从哪里开始？
首先，我很惊讶这是新闻。其次，问题不在于分析器不好，而在于某些分析器是坏的。作者建立了一个，他们认为，这是好的，只是通过避免他们在他们评估的那些中发现的一些错误。错误很常见，因为有关性能分析的一些持续存在的神话。
但让我们保持积极的态度。如果想找到加速的机会，这真的非常简单：
采样应与程序状态不相关。
这意味着在一个真正随机的时间发生，无论程序是在I / O中（用户输入除外），还是在GC中，还是在紧凑的CPU环路中，或者其他什么。
采样应读取函数调用堆栈，
以便确定在采样时哪些语句处于“活动”状态。原因是每个调用站点（调用函数的点）的百分比成本等于它在堆栈上的时间分数。（注意：本文完全关注自拍时间，忽略了大型软件中可避免函数调用的巨大影响。事实上，原版背后的原因是为了帮助找到这些电话。gprof
报告应按行（而不是按功能）显示百分比。
如果识别出“hot”函数，人们仍然必须在其中寻找考虑时间的“hot”代码行。该信息在示例中！为什么要隐藏它？
一个几乎普遍的错误（纸张共享）是过于关注测量的准确性，而对位置的准确性不够关注。例如，下面是一个性能调优示例，其中识别并修复了一系列性能问题，从而导致复合加速 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，“使用从调用堆栈采样派生的指令级成本进行性能调优”，ACM SIGPLAN Notices 42，8（2007年8月），第4-8页。
如果我没看错的话，这篇论文只讨论了基于样本的分析。许多探查器还执行基于检测的分析。它要慢得多，并且还有其他一些问题，但它不应该受到论文所谈论的偏见的影响。
这篇论文的结论是，我们不能真正相信分析器的结果。但是，使用探查器的替代方法是什么。
不。该论文的结论是，目前的轮廓仪的测量方法存在特定的缺陷。他们提出了一个解决方案。这篇论文是最近才发表的。我希望探查器最终实现此修复。在那之前，即使是有缺陷的分析器仍然比“感觉”好得多。
