第二轮排序更快

Question

作为学校练习的一部分，我想将排序算法作为 Java 练习进行比较和对比。

我自己实现了排序算法，我们对实现 Comparable 接口的类 Person 的对象进行排序。

到目前为止一切都很好，但我无法解释的是为什么在第一次调用我的排序方法时，排序时间比后续调用要长？
下面的输出代表我的结果。
Best、Worst 和 Avg 指的是传递给排序方法的未排序数组：

• 最好：数组已经排序
• 最差：数组倒序排列
• 平均：数组中的对象是随机顺序的

这是我的输出：

1-call of the sorting methods 
InsertionSort Best:1799ms    Worst:78ms  Avg:789ms   
MergeSort     Best:10ms      Worst:3ms   Avg:5ms     

2-call of the sorting methods 
InsertionSort Best:1065ms    Worst:39ms  Avg:691ms   
MergeSort     Best:3ms       Worst:2ms   Avg:5ms     

3-call of the sorting methods 
InsertionSort Best:1066ms    Worst:39ms  Avg:692ms   
MergeSort     Best:3ms       Worst:2ms   Avg:5ms     

4-call of the sorting methods 
InsertionSort Best:1065ms    Worst:39ms  Avg:691ms   
MergeSort     Best:3ms       Worst:2ms   Avg:5ms     

JVM 是否对后续调用进行任何优化？
我很困惑，非常感谢任何帮助！

编辑：感谢到目前为止的建议和回答！ 澄清几点 - 我的输出中的每个调用都指的是完成排序所需的时间！
每次排序后，我都会再次使用 UNSORTED 数组进行新调用！

我的源代码可以作为 Eclipse 项目的 zip 文件下载，位于以下 Dropbox 链接： dropbox link to eclipse project.zip

附：我没有使用探查器的经验 - 如果你能指点我一个教程，那就太好了。

Answer 1

正如各种各样的反应所表明的那样，这里有很多事情在起作用。

但第一次运行的长时间运行可能是由 JIT（即时）编译来解释的。作为discussed here，您的算法将作为解释字节码在JVM 中运行一段时间。当热点监视器确定您的排序循环成本很高时，JVM 会将它们编译为本机代码。在那之后，他们会跑得更快。第一次运行的缺点是在解释器中运行了一段时间，再加上编译的额外成本。这就是"warming up" is a common term in Java benchmarks 的原因。

不同输入的性能差异与排序算法有关。许多算法在初始数据组织的基础上表现不同，并且许多算法被故意组织以在初始排序或接近排序的数据上表现良好。 Here is a brilliant demonstration for the case of nearly sorted input。例如。插入排序通常是二次时间，但在几乎排序的输入上是线性时间（对于大小为 n 的输入，实际上是 O((k+1)n），其中元素距离正确排序不超过 k 个位置）。

然后是链接已经引用的分支预测问题。现代处理器具有各种机制，试图根据程序运行时收集的最近历史记录来“猜测”分支（本质上是机器级别的“if”语句）将走向何方。错误猜测的成本很高。猜测的好坏可能会受到算法和数据细节的影响。

Answer 2

由于Branch Prediction，处理排序数组比处理未排序数组更快。
这已在the most famous Stack Overflow question 中广泛进行了介绍。