为什么返回Java对象引用比返回原语要慢得多

时间：2015-04-06 14:01:23

标签： java low-latency jmh

我们正在研究对延迟敏感的应用程序，并对各种方法进行微基准测试（使用jmh）。在对查找方法进行微基准测试并对结果感到满意之后，我实现了最终版本，但却发现最终版本比我刚刚基准测试的慢3倍。

罪魁祸首是实施的方法返回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倍。

我认为返回枚举对象与整数之间的唯一区别是，一个返回64位值（引用），另一个返回32位值。我的一位同事猜测返回枚举会增加额外的开销，因为需要跟踪潜在GC的参考。 （但鉴于枚举对象是静态的最终引用，它似乎很奇怪，它需要这样做）。

性能差异的解释是什么？

更新

我分享了maven项目here，以便任何人都可以克隆它并运行基准测试。如果有人有时间/兴趣，那么看看其他人是否可以复制相同的结果会很有帮助。 （我在两台不同的机器上复制，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

2 个答案:

答案 0 :(得分：149)

TL; DR：你不应该把BLIND信任放入任何东西。

首先要做的事情是：在从实验数据中得出结论之前验证实验数据非常重要。声称有些东西快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方法，＆＃34;消费＆＃34;价值观（见Blackhole的理由）。 Blackhole.consume references和primitives的重载已经过载，仅此一项就足以证明性能差异。

有一个理由说明为什么这些方法看起来不同：他们试图尽可能快地为他们的论证类型。即使我们尝试匹配它们，它们也不一定表现出相同的性能特征，因此对于较新的JMH，结果更加对称。现在，您甚至可以转到-prof perfasm查看生成的测试代码，看看性能有何不同，但这超出了这一点。

如果您真的想要了解返回原语和/或引用在性能方面有何不同，则需要输入 大可怕的灰色区域 < / strong>细致入微的绩效基准。例如。像这个测试的东西：

@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

[讽刺]看看它有多容易！ [/讽刺]

模式是：问题越简单，就越需要努力做出合理可靠的答案。

答案 1 :(得分：6)

为了清除对引用和内存的一些误解（@Mzf），让我们深入研究Java虚拟机规范。 但在去那里之前，必须澄清一件事 - 永远无法从内存中检索对象，只有其字段可以。实际上，没有可以执行如此广泛操作的操作码。

本文档将引用定义为第一类的堆栈类型（因此它可能是执行堆栈操作的指令的结果或参数） - 采用单个堆栈字的类型类别（ 32位）。见表2.3 A list of Java Stack Types

此外，如果方法调用根据规范正常完成，则从堆栈顶部弹出的值将被推送到方法调用程序的堆栈上（第2.6.4节）。

您的问题是导致执行时间差异的原因。第2章前言答案：

  

不属于Java虚拟机规范的实现细节   会不必要地限制实施者的创造力。例如，   运行时数据区的内存布局，使用的垃圾收集算法，以及   任何Java虚拟机指令的内部优化（例如，   将它们翻译成机器代码）由执行者自行决定。

换句话说，因为出于逻辑原因（它最终只是int或float的叠加词），因此在文档中没有说明关于使用引用的性能惩罚这样的事情，所以离开时搜索你的实现的源代码或者根本没找到。

在某种程度上，我们实际上不应该总是责怪实施，在寻找答案时你可以找到一些线索。 Java定义了用于操作数字和引用的单独指令。参考操作指令以a开头（例如astore，aload或areturn），并且是允许使用引用的唯一指令。特别是您可能有兴趣查看areturn的实现。

相关问题
最新问题