Por qué devolver una referencia de objeto Java es mucho más lento que devolver una primitiva

TL; DR: Usted no debe poner una confianza ciega en nada.

Lo primero es lo primero: es importante verificar los datos experimentales antes de saltar a las conclusiones de ellos. Simplemente afirmar que algo es 3 veces más rápido/más lento es extraño, porque realmente necesita hacer un seguimiento de la razón de la diferencia de rendimiento, no solo confiar en los números. Esto es especialmente importante para nano-puntos de referencia como usted tiene.

Segundo, los experimentadores deben entender claramente lo que en su ejemplo particular, usted está devolviendo el valor de los métodos @Benchmark, pero ¿puede estar razonablemente seguro de que los llamantes externos harán lo mismo para primitive y la referencia? Si se hace esta pregunta, entonces se dará cuenta de que básicamente está midiendo la infraestructura de prueba.

Al grano. En mi máquina (i5-4210U, Linux x86_64, JDK 8u40), la prueba produce:

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

Está bien, por lo que las pruebas de referencia aparecen 3 veces más lento. Pero espera, utiliza un antiguo JMH (1.1.1), vamos a actualizar a la última actual (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

Oops, ahora son apenas más lentos. Por cierto, esto también nos dice que la prueba está vinculada a la infraestructura. Vale, ¿podemos ver lo que realmente sucede?

Si construyes los puntos de referencia, y miras a tu alrededor lo que llama exactamente tus métodos @Benchmark, entonces verás algo como:

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;
}

Que l_blackhole1_1 tiene un método consume, que "consume" los valores (ver Blackhole para la justificación). Blackhole.consume tiene sobrecargas para referenciasy primitivas, y eso por sí solo es suficiente para justificar la diferencia de rendimiento.

Hay una razón por la que estos métodos se ven diferentes: están tratando de ser lo más rápido posible para sus tipos de argumento. No necesariamente exhiben las mismas características de rendimiento, a pesar de que tratamos de igualarlas, de ahí el resultado más simétrico con JMH más nuevo. Ahora, incluso puede ir a -prof perfasm para ver el código generado para sus pruebas y ver por qué el el rendimiento es diferente, pero eso está más allá del punto aquí.

Si realmente quiere entender cómo el retorno de la primitiva y / o referencia difiere en cuanto al rendimiento, tendría que introducir un gran zona gris aterradora de benchmarking de desempeño matizado. Por ejemplo, algo como esta prueba:

@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;
    }

}

...que produce el mismo resultado para primitivas y referencias:

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

Como dije anteriormente, estas pruebas requieren el seguimiento de la razones de los resultados. En este caso, el código generado para ambos es casi el mismo, y eso explica el resultado.

Prim:

                  [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   

[sarcasmo] ¡Mira lo fácil que es! [/sarcasmo]

El patrón es: cuanto más simple es la pregunta, más tienes que trabajar para hacer una respuesta plausible y confiable.