scala - 使用 Scala 的 REPL 进行性能基准比较是否合理？

Question

Scala 的 REPL 是交互式测试某些代码片段的绝佳场所。最近，我一直在使用 REPL 进行一些性能比较，以重复执行操作并比较测量挂钟时间。

这是我最近创建的一个示例，用于帮助回答 SO 问题 [1][2]:

// Figure out the perfomance difference between direct method invocation and reflection-based method.invoke

def invoke1[T,U](obj:Any, method:Method)(param:T):U = method.invoke(obj,Seq(param.asInstanceOf[java.lang.Object]):_*) match { 
    case x: java.lang.Object if x==null => null.asInstanceOf[U]
    case x => x.asInstanceOf[U]
}

def time[T](b: => T):(T, Long) = {
    val t0 = System.nanoTime()
    val res = b
    val t = System.nanoTime() - t0
    (res,t )
}

class Test {
  def op(l:Long): Long = (2 until math.sqrt(l).toInt).filter(x=>l%x==0).sum
}

val t0 = new Test

val method = classOf[Test].getMethods.find(_.getName=="op").get

def timeDiff = {
  val (timeDirectCall,res) = time { (0 to 1000000).map(x=>t0.op(x)) }
  val (timeInvoke, res2) = time { (0 to 1000000).map(x=>{val res:Long=invoke1(t0,method)(x);res}) }
  (timeInvoke-timeDirectCall).toDouble/timeDirectCall.toDouble
}


//scala> timeDiff
//res60: Double = 2.1428745665357445
//scala> timeDiff
//res61: Double = 2.1604176409796683

在另一种情况下，我一直在生成随机数据点的 MM 来比较开源项目的并发模型。 REPL 非常适合使用不同的配置，无需代码-编译-测试周期。

我知道常见的基准测试陷阱，例如 JIT 优化和预热的需要。

我的问题是:

• 使用时是否需要考虑任何 REPL 特定元素它可以执行宏观基准的比较微观吗？

• 这些测量值相对使用时可靠吗？即他们能否回答以下问题:A 比 B 快吗？

• 相同代码的预消除执行是 jit 的良好预热吗编译器？

• 还有其他需要注意的问题吗？

[1] Scala reflection: How to pass an object's method as parameter to another method

[2] https://gist.github.com/maasg/6808879

Answer 1

这是一个很好的问题。我无法想象为什么有人反对它。

其中一条评论完全错误，这一事实表明 REPL 需要在 scala-lang.org 的常见问题解答或教程中占有一席之地。快速搜索后我找不到描述性论文。

答案是肯定的，REPL 会满足您的期望。

Here is an old page为什么这个问题很有趣:REPL 感觉是动态的，但实际上是静态编译的。正如链接页面上的即兴评论所说，它“跨越了两个世界”。

REPL 将每一行编译成它自己的包装对象。每个这样的对象都会从交互式 session 的历史记录中导入符号，这就是代码神奇地引用前几行的方式。一切都是编译的，所以当它运行时，可以这么说，它是在 JVM 上本地运行的；没有额外的解释器层。这就是 REPL 的 killer 级设计功能。

这就是为什么你的问题的答案是肯定的，你的代码以编译代码的速度运行。调用方法不需要重新编译所有历史记录。

Here's another old link显示其他人对时间和微基准测试也有同样的问题。

目前有an open issue使自定义 REPL 如何包装代码行成为可能。微基准测试是一个有趣的用例，其中代码可以包装在任意基准测试框架中。这很快就会实现。

基准测试框架应该负责热身。由于提交给 REPL 的每个表达式都是单独编译的(尽管是由同一个编译器)，因此您会注意到，一个方法可能第一次被冷调用，第二次被热调用(由 scalac 进行模内联)。

警告:

使用-Yrepl-class-based或注意不要将计算放入包装对象的静态初始化程序中。

Here is some sample confusion和 here is the same question ，隐蔽性较差。