探查器可以更改递归调用在 Java 中运行的时间吗？答案

【问题标题】：Can a profiler change how long recursive calls take to run in Java?探查器可以更改递归调用在 Java 中运行的时间吗？
【发布时间】：2011-01-28 22:28:11
【问题描述】：

我正在用 Java 重构一些代码，所以我正在计时以确保代码不会变慢。但是，新的重构代码似乎比原始代码花费了更多的时间。值得注意的是，当我使用分析器运行代码时，新代码比旧代码快得多。主要区别在于旧代码是递归的，而新代码是迭代的。分析器能否对递归代码产生数十万倍的影响，而对迭代代码的影响仅为 1.5 倍？

我在 Mac OS X 10.6.6、3 GB RAM、2.4 GHz CPU 上运行，使用带有 Java 1.6.0__22 64 位服务器的默认 Netbeans 6.9 分析器。

（这两种方法都有使用 System.currentTimeMillis() 的自计时代码，让我可以在不使用分析器时比较时间，但这不会显着影响事情。）

【问题讨论】：

您使用的是什么分析器？探查器是否使您的代码在与正常情况不同的 JVM 中运行？
@Andrew Netbeans 默认，但我不知道它是否使用不同的 JVM（不过我怀疑它确实如此）。

标签： java recursion profiling performance

【解决方案1】：

是的。大多数配置文件在方法调用级别进行检测。在递归形式中，分析器必须进行比迭代形式更多的测量。虽然分析器确实试图从报告的数字中提取他们的开销，但这很难做到可靠。不同的分析器在这方面会更好/更差。

【讨论】：

【解决方案2】：

我正在用 Java 重构一些代码，所以我正在计时以确保代码不会变慢。但是，新的重构代码似乎比原始代码花费了更多的时间。

是的。代码通常在分析器下运行较慢。

因此，您应该比较应用程序的旧版本/新版本的时间，要么都在分析器下运行，要么都正常运行。

还要注意，分析器实际上可以distort performance characteristics。并且不同的分析器可能不同意代码热点的位置。因此，在采用您正在试用的优化之前，最好在不进行分析的情况下运行/比较应用程序的版本。

（这两种方法都有使用 System.currentTimeMillis() 的自计时代码，让我可以在不使用分析器时比较时间，但这不会显着影响事情。）

这里也有陷阱：

currentTimeMillis() 的最佳粒度是 1 毫秒，但在某些操作系统上可能是几十毫秒。
如果您不采取措施避免这种情况，您的手动计时可能包括扭曲的开销，例如 JIT 编译时间和 GC 时间。效果可能非常微妙。

【讨论】：

我认为这是分析器扭曲性能特征的一个典型例子。
考虑使用通常至少精确到微秒的 nanoTime() 而不是 currentTimeMillis()。

【解决方案3】：

我想说，如果你想衡量速度，就只衡量速度，不要分析。他们不是一回事。检测分析器会在每个函数调用中增加大量开销，如果您想要的只是整体速度差异，那么它是不准确的，因为您部分地测量了检测本身的成本。

如果您想了解什么在花费时间，这与衡量是不同的。报告行级百分比的挂钟时间堆栈采样分析器（不是仪器）是您最好的选择。它是否会减慢程序的速度并不重要，因为它的目的不是测量速度；它的目的是找出时间的去向和原因，以百分比为基础。如果它或其他东西将程序减慢 10% 或 10 倍，那就没问题了，如果它显示您在哪里花费了时间，与速度无关。

我之所以这么说，是因为很多人对这一点感到困惑，而这种困惑被固化到了很多分析器中。