Javaオブジェクトの参照を返すと、プリミティブを返すよりずっと遅いのはなぜか

原因は、実装されたメソッドが enum オブジェクトではなく int . 以下は、ベンチマークコードの簡略版です。

@OutputTimeUnit(TimeUnit.MICROSECONDS)
@State(Scope.Thread)
public class ReturnEnumObjectVersusPrimitiveBenchmark {

    enum Category {
        CATEGORY1,
        CATEGORY2,
    }

    @Param( {"3", "2", "1" })
    String value;

    int param;

    @Setup
    public void setUp() {
        param = Integer.parseInt(value);
    }

    @Benchmark
    public int benchmarkReturnOrdinal() {
        if (param < 2) {
            return Category.CATEGORY1.ordinal();
        }
        return Category.CATEGORY2.ordinal();        
    }


    @Benchmark
    public Category benchmarkReturnReference() {
        if (param < 2) {
            return Category.CATEGORY1;
        }
        return Category.CATEGORY2;      
    }


    public static void main(String[] args) throws RunnerException {
            Options opt = new OptionsBuilder().include(ReturnEnumObjectVersusPrimitiveBenchmark.class.getName()).warmupIterations(5)
                .measurementIterations(4).forks(1).build();
        new Runner(opt).run();
    }

}

上記のベンチマーク結果です。

# VM invoker: C:\Program Files\Java\jdk1.7.0_40\jre\bin\java.exe
# VM options: -Dfile.encoding=UTF-8

Benchmark                   (value)   Mode  Samples     Score     Error   Units
benchmarkReturnOrdinal            3  thrpt        4  1059.898 ±  71.749  ops/us
benchmarkReturnOrdinal            2  thrpt        4  1051.122 ±  61.238  ops/us
benchmarkReturnOrdinal            1  thrpt        4  1064.067 ±  90.057  ops/us
benchmarkReturnReference          3  thrpt        4   353.197 ±  25.946  ops/us
benchmarkReturnReference          2  thrpt        4   350.902 ±  19.487  ops/us
benchmarkReturnReference          1  thrpt        4   339.578 ± 144.093  ops/us

関数の戻り値の型を変更するだけで、パフォーマンスがほぼ3倍も変わりました。

enum オブジェクトを返すか整数を返すかの唯一の違いは、一方が 64 ビットの値 (参照) を返し、もう一方が 32 ビットの値を返すことだと考えていました。 私の同僚の 1 人は、enum を返すと、GC の可能性のために参照を追跡する必要があるので、追加のオーバーヘッドが追加されると推測していました。 (しかし、enum オブジェクトが静的な最終参照であることを考えると、それを行う必要があるのは奇妙に思われます）。

パフォーマンスの違いの説明は何ですか?

アップデイト

mavenプロジェクトを共有しました。 ここで を共有しましたので、誰でもそれをクローンしてベンチマークを実行することができます。 もし時間があれば、他の人が同じ結果を再現できるかどうかを確認するのに役立つと思います。 (私は 2 つの異なるマシン、Windows 64 と Linux 64 で、どちらも Oracle Java 1.7 JVM のフレーバーを使って再現しました)。 ZhekaKozlovは、メソッド間の違いは見られなかったと述べています。

実行方法: (リポジトリのクローン後)

mvn clean install
java -jar .\target\microbenchmarks.jar function.ReturnEnumObjectVersusPrimitiveBenchmark -i 5 -wi 5 -f 1

どのように解決するのですか？

TL;DR：何事も盲目的に信じてはいけない。

まず最初に、実験データから結論を出す前に、それを検証することが重要です。何かが 3 倍速い/遅いと主張するだけではおかしいです。単に数字を信用するのではなく、性能差の理由を本当にフォローアップする必要があるからです。これは、あなたが持っているようなナノ ベンチマークでは特に重要です。

第二に、実験者は何を制御し、何を制御しないかを明確に理解する必要があります。あなたの特定の例では、あなたは @Benchmark メソッドから値を返していますが、外の呼び出し元がプリミティブと参照に対して同じことをすると合理的に確信できるでしょうか？この質問を自分自身に投げかけたら、基本的にテスト インフラストラクチャを測定していることに気づくでしょう。

本題に入ります。私のマシン (i5-4210U, Linux x86_64, JDK 8u40) では、テストは結果を出しました。

Benchmark                    (value)   Mode  Samples  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt        5  0.876 ± 0.023  ops/ns
...benchmarkReturnOrdinal          2  thrpt        5  0.876 ± 0.009  ops/ns
...benchmarkReturnOrdinal          1  thrpt        5  0.832 ± 0.048  ops/ns
...benchmarkReturnReference        3  thrpt        5  0.292 ± 0.006  ops/ns
...benchmarkReturnReference        2  thrpt        5  0.286 ± 0.024  ops/ns
...benchmarkReturnReference        1  thrpt        5  0.293 ± 0.008  ops/ns

さて、参照テストは3倍遅く表示されます。しかし待ってください、これは古いJMH（1.1.1）を使っているのです、現在の最新（1.7.1）に更新しましょう。

Benchmark                    (value)   Mode  Cnt  Score   Error   Units
...benchmarkReturnOrdinal          3  thrpt    5  0.326 ± 0.010  ops/ns
...benchmarkReturnOrdinal          2  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnOrdinal          1  thrpt    5  0.329 ± 0.004  ops/ns
...benchmarkReturnReference        3  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        2  thrpt    5  0.288 ± 0.005  ops/ns
...benchmarkReturnReference        1  thrpt    5  0.288 ± 0.002  ops/ns

おっと、これでかろうじて遅くなっただけですね。ところで、これはテストがインフラストラクチャーに依存していることも示しています。さて、実際に何が起こるか見てみましょうか。

ベンチマークを構築し、あなたの @Benchmark メソッドを呼び出しているのかを見てみると、以下のようなことがわかります。

public void benchmarkReturnOrdinal_thrpt_jmhStub(InfraControl control, RawResults result, ReturnEnumObjectVersusPrimitiveBenchmark_jmh l_returnenumobjectversusprimitivebenchmark0_0, Blackhole_jmh l_blackhole1_1) throws Throwable {
    long operations = 0;
    long realTime = 0;
    result.startTime = System.nanoTime();
    do {
        l_blackhole1_1.consume(l_longname.benchmarkReturnOrdinal());
        operations++;
    } while(!control.isDone);
    result.stopTime = System.nanoTime();
    result.realTime = realTime;
    result.measuredOps = operations;
}

それは l_blackhole1_1 には consume メソッドがあり、これは値を消費します ( Blackhole を参照)。 Blackhole.consume にはオーバーロードがあり 参照 と プリミティブ であり、これだけでもパフォーマンスの違いを正当化するのに十分です。

これらのメソッドが異なるように見えるのには根拠があります。これらのメソッドは、引数のタイプに対して可能な限り高速になるように試みていますが、必ずしも同じパフォーマンス特性を示すわけではありません。現在では、さらに -prof perfasm で生成されたテスト用のコードを見て、なぜパフォーマンスが異なるのかを確認することもできますが、ここではその話は割愛します。

もしあなたが本当に を望むなら プリミティブや参照を返すことがパフォーマンス的にどのように異なるかを理解するために、以下のように 大きな怖いグレーゾーン ニュアンスのあるパフォーマンス ベンチマークのようなものです。たとえば、このテストのようなものです。

@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(5)
public class PrimVsRef {

    @Benchmark
    public void prim() {
        doPrim();
    }

    @Benchmark
    public void ref() {
        doRef();
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private int doPrim() {
        return 42;
    }

    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    private Object doRef() {
        return this;
    }

}

...これは、プリミティブとリファレンスで同じ結果をもたらします。

Benchmark       Mode  Cnt  Score   Error  Units
PrimVsRef.prim  avgt   25  2.637 ± 0.017  ns/op
PrimVsRef.ref   avgt   25  2.634 ± 0.005  ns/op

上で述べたように、これらのテストは を必要とします。 をフォローすることで、その結果の理由を知ることができます。この場合、両方の生成されたコードはほとんど同じであり、それが結果を説明しています。

プリムです。

                  [Verified Entry Point]
 12.69%    1.81%    0x00007f5724aec100: mov    %eax,-0x14000(%rsp)
  0.90%    0.74%    0x00007f5724aec107: push   %rbp
  0.01%    0.01%    0x00007f5724aec108: sub    $0x30,%rsp         
 12.23%   16.00%    0x00007f5724aec10c: mov    $0x2a,%eax   ; load "42"
  0.95%    0.97%    0x00007f5724aec111: add    $0x30,%rsp
           0.02%    0x00007f5724aec115: pop    %rbp
 37.94%   54.70%    0x00007f5724aec116: test   %eax,0x10d1aee4(%rip)        
  0.04%    0.02%    0x00007f5724aec11c: retq  

ref:

                  [Verified Entry Point]
 13.52%    1.45%    0x00007f1887e66700: mov    %eax,-0x14000(%rsp)
  0.60%    0.37%    0x00007f1887e66707: push   %rbp
           0.02%    0x00007f1887e66708: sub    $0x30,%rsp         
 13.63%   16.91%    0x00007f1887e6670c: mov    %rsi,%rax     ; load "this"
  0.50%    0.49%    0x00007f1887e6670f: add    $0x30,%rsp
  0.01%             0x00007f1887e66713: pop    %rbp
 39.18%   57.65%    0x00007f1887e66714: test   %eax,0xe3e78e6(%rip)
  0.02%             0x00007f1887e6671a: retq   

[皮肉] どれほど簡単か見てみましょう! [/sarcasm]です。

このパターンは、質問が簡単であればあるほど、もっともらしく信頼できる答えを作るために工夫しなければならないことが多くなるということです。