为什么在Scala中独立代码块的执行时间依赖于执行顺序？[副本]

Question

我有一个用Scala写的程序。我想测量不同独立代码块的执行时间。当我以明显的方式（即在每个块之前和之后插入system.nanotime())时，我观察到执行时间取决于块的顺序。前几个块总是比其他块花更多的时间。

我创建了一个再现这种行为的极简示例。所有代码块都是相同的，为了简单起见，为整数数组调用hashCode()。

package experiments

import scala.util.Random

/**
  * Measuring execution time of a code block
  *
  * Minimalistic example
  */
object CodeBlockMeasurement {

  def main(args: Array[String]): Unit = {
    val numRecords = args(0).toInt
    // number of independent measurements
    val iterations = args(1).toInt

    // Changes results a little bit, but not too much
    // val records2 = Array.fill[Int](1)(0)
    // records2.foreach(x => {})

    for (_ <- 1 to iterations) {
      measure(numRecords)
    }
  }

  def measure(numRecords: Int): Unit = {
    // using a new array every time
    val records = Array.fill[Int](numRecords)(new Random().nextInt())
    // block of code to be measured
    def doSomething(): Unit = {
      records.foreach(k => k.hashCode())
    }
    // measure execution time of the code-block
    elapsedTime(doSomething(), "HashCodeExperiment")
  }

  def elapsedTime(block: => Unit, name: String): Unit = {
    val t0 = System.nanoTime()
    val result = block
    val t1 = System.nanoTime()
    // print out elapsed time in milliseconds
    println(s"$name took ${(t1 - t0).toDouble / 1000000} ms")
  }
}

运行numrecords=100000和iterations=10的程序后，我的控制台如下所示：

HashCodeExperiment耗时14.630283毫秒
HashCodeExperiment耗时7.125693毫秒
HashCodeExperiment耗时0.368151毫秒
HashCodeExperiment耗时0.431628毫秒
HashCodeExperiment耗时0.086455毫秒
HashCodeExperiment耗时0.056458毫秒
HashCodeExperiment耗时0.055138毫秒
HashCodeExperiment耗时0.062997毫秒
HashCodeExperiment耗时0.063736毫秒
HashCodeExperiment耗时0.056682毫秒

有人能解释为什么吗？不应该都一样吗？哪个是真正的执行时间？

非常感谢，彼得

环境参数:
OS:ubuntu 14.04 LTS（64位）
IDE:IntelliJ IDEA 2016.1.1(IU-145.597)
Scala:2.11.7

Answer 1

这是Java的JIT在起作用。最初执行的是普通字节码，但过了一段时间（Oracle JVM默认情况下是1.5K/10K调用，请参见-xx:compilethreshold)后，优化开始处理实际执行的本机代码，这通常会导致性能的显著提高。

正如Ivan所提到的，还有中间字节码/本机代码的缓存和涉及到的各种其他技术，其中最重要的技术之一是垃圾收集器本身，它会给单个结果带来更多的差异。根据代码分配新对象的程度，这可能会在GC发生时完全破坏性能，但这是一个单独的问题。

为了在微基准测试时去除这些异常结果，建议您对操作的多个迭代进行基准测试，并丢弃底部和顶部5..10%的结果，然后根据剩余的样本进行性能评估。