Java如果没有分析器，那么我们还有其他选择吗？
看完Joshua Bloch的演讲“ Performance Anxiety”后，我阅读了他在演讲“ Evaluation of Java Profillers的准确性”中建议的论文。引用结论：
我们的结果令人不安，因为它们表明配置文件不正确是普遍存在的-在我们的七个基准测试中的大多数以及两个生产JVM中（而且很重要），所有四个最新的配置文件都产生不正确的配置文件。不正确的配置文件很容易导致性能分析人员花时间优化对方法的影响最小的冷方法。我们表明，不使用屈服点进行采样的概念证明配置文件不会遇到上述问题
本文的结论是，我们不能真正相信分析器的结果。但是，使用分析器的替代方法是什么。我们应该回过头去只是用自己的感觉进行优化吗？
回答：
首先，我很惊讶这是新闻。其次，问题不在于探查器是坏的，而是某些探查器是坏的。作者认为，这只是通过避免在评估的错误中发现的一些错误，才建立了一个不错的错误。由于存在一些有关性能分析的长期存在的误解，因此经常会犯错误。
但是，让我们保持乐观。如果想找到加速的机会，那真的很简单：
采样应与程序状态无关。
这意味着在真正随机的时间发生，而不管程序是在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页。
以上是 Java如果没有分析器，那么我们还有其他选择吗？ 的全部内容， 来源链接： utcz.com/qa/398519.html
