如果探查器不是答案，我们还有其他选择吗？

Question

在观看Joshua Bloch的演出“表现焦虑”之后，我阅读了他在演讲中提出的论文"Evaluating the Accuracy of Java Profilers"。引用结论：

  

我们的结果令人不安，因为它们表明，在我们的七个基准测试和两个生产JVM中，普遍存在的错误是普遍存在的 - 并且显着 - 所有四个   最先进的专业人士会产生不正确的专业知识。不正确   专业人士很容易让性能分析师花时间优化对性能影响最小的冷​​方法。   我们展示了一个不使用产量的概念验证问题   抽样点不会出现上述问题

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

更新：讨论中似乎遗漏的一点是观察者效应。我们可以构建一个真正“观察者效应”的探查器 - 免费吗？

Answer 1

Answer 2

如果我正确阅读，该论文仅讨论基于样本的分析。许多分析器也进行基于仪器的分析。它速度慢得多，还有一些其他问题，但不应该受到论文所说的偏见的影响。

  

论文的结论是我们   真的不能相信结果   剖析。但那么，是什么   使用分析器的替代方法。

没有。论文的结论是当前剖面仪的测量方法存在特定缺陷。他们提出修复方案。这篇论文是最近的。我希望剖析器最终能够实现这个修复。在那之前，即使是有缺陷的分析器仍然比“感觉”好得多。

Answer 3

除非您正在构建需要每个CPU周期的前沿应用程序，否则我发现分析器是查找代码中10％最慢部分的好方法。作为开发人员，我认为在几乎所有情况下都应该是你真正关心的。

我有http://www.dynatrace.com/en/的经验，我可以告诉你它很擅长找到低悬的果实。

Profilers就像任何其他工具一样，他们有他们的怪癖，但我会相信他们可以在任何一天找到你应用中的热点来查看。

Answer 4

如果您不信任探查器，那么您可以通过使用面向方面的编程进入偏执模式，绕过应用程序中的每个方法，然后使用记录器记录每个方法调用。

您的应用程序确实会变慢，但至少您将精确计算每种方法被调用的次数。如果您还想查看每个方法执行所需的时间，请环绕每个方法perf4j。

将所有这些统计信息转储到文本文件后，使用一些工具提取所有必要信息，然后将其可视化。我想这可以让你很好地了解你的应用程序在某些地方的速度有多慢。

Answer 5

实际上，您最好在数据库级别进行性能分析。大多数企业数据库都能够在一段时间内显示最常见的查询。开始处理这些查询，直到顶部查询达到300毫秒或更短，您将取得很大进展。 Profilers对于显示堆的行为和识别被阻塞的线程非常有用，但我个人从未对开发团队在识别热方法或大型对象方面有太多牵引力。