3

次の非常に単純なコードを検討してください。

class A(val a: String, val b: Int)
object Test {
  implicit class wrap(obj: A) {
    def fn = obj.a + obj.b
  }

  def main(args: Array[String]) =
    println(new A("Hello", 1).fn)
}

コードを逆アセンブルすると、次のようになります。

public void main(java.lang.String[]);
  Code:
   0:   getstatic   #29; //Field scala/Predef$.MODULE$:Lscala/Predef$;
   3:   aload_0
   4:   new #31; //class A
   7:   dup
   8:   ldc #33; //String Hello
   10:  iconst_1
   11:  invokespecial   #36; //Method A."<init>":(Ljava/lang/String;I)V
   14:  invokevirtual   #38; //Method wrap:(LA;)LTest$wrap;
   17:  invokevirtual   #42; //Method Test$wrap.fn:()Ljava/lang/String;
   20:  invokevirtual   #46; //Method scala/Predef$.println:(Ljava/lang/Object;)V
   23:  return

fnコンパイラは、暗黙的に使用する場合、効果的にラッパー オブジェクトを作成します。

JIT コンパイルがこれを排除できること、時期尚早の最適化は良くないこと、そしてほとんどのコードでパフォーマンスの問題に遭遇する可能性が低いことは十分承知していますが、内部で静的関数を作成することはないようです。コンパイラの多くの作業のように、これを排除します。

では、ちょっと興味があります。Scala チームがこの最適化を含めないことにした特別な理由はありますか?

4

1 に答える 1