scala - 尽管是包装器，但 CollectionConverters 的性能代价高昂？

Question

AFAIU, CollectionConverters 包装器只是将调用委托(delegate)给底层集合，因此成本应该是单个对象分配，然后是单个方法调用间接，例如，Conversion Between Java and Scala Collections状态

Internally, these conversion work by setting up a “wrapper” object that forwards all operations to the underlying collection object. So collections are never copied when converting between Java and Scala.

分析 SetWrapper 事实上，我们看到它只是将调用委托(delegate)给 underlying收藏

class SetWrapper[A](underlying: Set[A]) extends ju.AbstractSet[A] with Serializable { self =>
  ...
  def size = underlying.size
  ...
}

但是，请考虑以下 jmh 基准

import org.openjdk.jmh.annotations._
import scala.jdk.CollectionConverters._
import java.{util => ju}

@State(Scope.Benchmark)
@BenchmarkMode(Array(Mode.Throughput))
class So31830028 {
  val size = 1000000
  val scalaSet: Set[Int] = (1 to size).toSet
  val javaSet: ju.Set[Int]  = (1 to size).toSet.asJava

  @Benchmark def scala = scalaSet.size
  @Benchmark def scalaAsJava = scalaSet.asJava.size
  @Benchmark def java = javaSet.size
  @Benchmark def javaAsScala = javaSet.asScala.size
}

在哪里 sbt "jmh:run -i 10 -wi 5 -f 2 -t 1 bench.So31830028"给

[info] Benchmark                     Mode  Cnt          Score          Error   Units
[info] So31830028.java              thrpt   20  356515729.840 ± 64691657.672   ops/s
[info] So31830028.javaAsScala       thrpt   20  270053471.338 ± 36854051.611   ops/s
[info] So31830028.scala             thrpt   20  448415156.726 ± 53674976.259   ops/s
[info] So31830028.scalaAsJava       thrpt   20  211808793.234 ± 57898858.737   ops/s

为什么如果 CollectionConverters 似乎会有显着的性能损失？是简单的包装？

这个问题的灵感来自 Cost of implicit conversion from java to scala collections

Answer 1

在 2.12 中，scalaSet.size是 just a field access ;对于 2.13，这是对 a final class 的简单字段访问器调用，这应该很容易内联，所以

a single object allocation and then single method call indirection

与此相比，这可能是一笔不小的开销。

我不明白 java 之间的区别和 javaAsScala (编辑:呃，这是另一种间接方式)。