Java 12和Java 8的流API在使用-gc true时,微基准测试结果令人费解。

56

作为我对使用复杂过滤器或在流中使用多个过滤器之间差异的研究的一部分,我注意到Java 12上的性能比Java 8慢得多。

这些奇怪结果有任何解释吗?我错过了什么吗?

配置:

  • java 8

    • OpenJDK Runtime Environment(版本1.8.0_181-8u181-b13-2〜deb9u1-b13)
    • OpenJDK 64位Server VM(构建25.181-b13,混合模式)
  • java 12

    • OpenJDK Runtime Environment(版本12+33)
    • OpenJDK 64位Server VM(构建12+33,混合模式,共享)
  • VM选项:-XX:+UseG1GC -server -Xmx1024m -Xms1024m

  • CPU:8核

JMH吞吐量结果

  • Warmup: 每次10次迭代,持续1秒
  • Measurement: 每次10次迭代,持续1秒
  • Threads: 1个线程,将同步迭代
  • Units: 操作/秒

比较表格

代码

流+复杂过滤器

public void complexFilter(ExecutionPlan plan, Blackhole blackhole) {
        long count = plan.getDoubles()
                .stream()
                .filter(d -> d < Math.PI
                        && d > Math.E
                        && d != 3
                        && d != 2)
                .count();

        blackhole.consume(count);
    }

流 + 多个筛选器

public void multipleFilters(ExecutionPlan plan, Blackhole blackhole) {
        long count = plan.getDoubles()
                .stream()
                .filter(d -> d > Math.PI)
                .filter(d -> d < Math.E)
                .filter(d -> d != 3)
                .filter(d -> d != 2)
                .count();

        blackhole.consume(count);
    }

并行流 + 复杂筛选器

public void complexFilterParallel(ExecutionPlan plan, Blackhole blackhole) {
        long count = plan.getDoubles()
                .stream()
                .parallel()
                .filter(d -> d < Math.PI
                        && d > Math.E
                        && d != 3
                        && d != 2)
                .count();

        blackhole.consume(count);
    }

并行流 + 多个过滤器

public void multipleFiltersParallel(ExecutionPlan plan, Blackhole blackhole) {
        long count = plan.getDoubles()
                .stream()
                .parallel()
                .filter(d -> d > Math.PI)
                .filter(d -> d < Math.E)
                .filter(d -> d != 3)
                .filter(d -> d != 2)
                .count();

        blackhole.consume(count);
    }

传统的Java迭代方式

public void oldFashionFilters(ExecutionPlan plan, Blackhole blackhole) {
        long count = 0;
        for (int i = 0; i < plan.getDoubles().size(); i++) {
            if (plan.getDoubles().get(i) > Math.PI
                    && plan.getDoubles().get(i) > Math.E
                    && plan.getDoubles().get(i) != 3
                    && plan.getDoubles().get(i) != 2) {
                count = count + 1;
            }
        }

        blackhole.consume(count);
    }

您可以通过运行docker命令自行尝试:

对于Java 8:

docker run -it volkodav/java-filter-benchmark:java8

对于Java 12:

docker run -it volkodav/java-filter-benchmark:java12

源代码:

https://github.com/volkodavs/javafilters-benchmarks


21
这些数字的意思是什么? - marstran
8
你的配置中,-gc true 很可能会影响到 JDK12 的运行。在每次迭代之前强制进行 Full GC 可能会扰乱垃圾回收的启发式算法。你为什么要开启这个选项呢?请注意不改变原意且使句子更通俗易懂。 - Aleksey Shipilev
9
还有,为什么要使用@Setup(Level.Invocation)?好像你的负载想要一次性收集所有陷阱 :) - Aleksey Shipilev
7
答案可能太复杂了,不适合在评论中呈现。这个差异似乎是真实存在的,而且在JDK12的情况下存在一些奇怪的内联问题,可以通过使用“-prof perfasm”命令来观察到。 - Aleksey Shipilev
12
我现在认为完全垃圾回收和并发编译之间存在奇怪的相互作用。由于很多原因,不建议使用“-gc true”,这可能是其中的一个新原因。仍在深入研究中... - Aleksey Shipilev
显示剩余14条评论
1个回答

24

感谢大家的帮助,特别是 @Aleksey Shipilev!

应用 JMH 基准测试更改后,结果看起来更加真实 (?)

更改:

  1. 更改安装方法以在基准测试的每个迭代之前/之后执行。

    @Setup(Level.Invocation) -> @Setup(Level.Iteration)

  2. 停止 JMH 在每次迭代之间强制进行 GC。在每次迭代之前强制进行 Full GC 很可能会破坏 GC 启发式算法。(c) Aleksey Shipilev

    -gc true -> -gc false

注意:默认情况下为 gc false。

比较表格

根据新的性能基准测试,Java 12 的性能与 Java 8 相比没有降低。

注意:更改后,小型数组大小的吞吐量误差显著增加了超过 100%,对于大型数据集保持不变。

结果表格

原始结果

Java 8

# Run complete. Total time: 04:36:29

Benchmark                                (arraySize)   Mode  Cnt         Score         Error  Units
FilterBenchmark.complexFilter                     10  thrpt   50   5947577.648 ±  257535.736  ops/s
FilterBenchmark.complexFilter                    100  thrpt   50   3131081.555 ±   72868.963  ops/s
FilterBenchmark.complexFilter                   1000  thrpt   50    489666.688 ±    6539.466  ops/s
FilterBenchmark.complexFilter                  10000  thrpt   50     17297.424 ±      93.890  ops/s
FilterBenchmark.complexFilter                 100000  thrpt   50      1398.702 ±      72.820  ops/s
FilterBenchmark.complexFilter                1000000  thrpt   50        81.309 ±       0.547  ops/s
FilterBenchmark.complexFilterParallel             10  thrpt   50     24515.743 ±     450.363  ops/s
FilterBenchmark.complexFilterParallel            100  thrpt   50     25584.773 ±     290.249  ops/s
FilterBenchmark.complexFilterParallel           1000  thrpt   50     24313.066 ±     425.817  ops/s
FilterBenchmark.complexFilterParallel          10000  thrpt   50     11909.085 ±      51.534  ops/s
FilterBenchmark.complexFilterParallel         100000  thrpt   50      3260.864 ±     522.565  ops/s
FilterBenchmark.complexFilterParallel        1000000  thrpt   50       406.297 ±      96.590  ops/s
FilterBenchmark.multipleFilters                   10  thrpt   50   3785766.911 ±   27971.998  ops/s
FilterBenchmark.multipleFilters                  100  thrpt   50   1806210.041 ±   11578.529  ops/s
FilterBenchmark.multipleFilters                 1000  thrpt   50    211435.445 ±   28585.969  ops/s
FilterBenchmark.multipleFilters                10000  thrpt   50     12614.670 ±     370.086  ops/s
FilterBenchmark.multipleFilters               100000  thrpt   50      1228.127 ±      21.208  ops/s
FilterBenchmark.multipleFilters              1000000  thrpt   50        99.149 ±       1.370  ops/s
FilterBenchmark.multipleFiltersParallel           10  thrpt   50     23896.812 ±     255.117  ops/s
FilterBenchmark.multipleFiltersParallel          100  thrpt   50     25314.613 ±     169.724  ops/s
FilterBenchmark.multipleFiltersParallel         1000  thrpt   50     23113.388 ±     305.605  ops/s
FilterBenchmark.multipleFiltersParallel        10000  thrpt   50     12676.057 ±     119.555  ops/s
FilterBenchmark.multipleFiltersParallel       100000  thrpt   50      3373.367 ±     211.108  ops/s
FilterBenchmark.multipleFiltersParallel      1000000  thrpt   50       477.870 ±      70.878  ops/s
FilterBenchmark.oldFashionFilters                 10  thrpt   50  45874144.758 ± 2210325.177  ops/s
FilterBenchmark.oldFashionFilters                100  thrpt   50   4902625.828 ±   60397.844  ops/s
FilterBenchmark.oldFashionFilters               1000  thrpt   50    662102.438 ±    5038.465  ops/s
FilterBenchmark.oldFashionFilters              10000  thrpt   50     29390.911 ±     257.311  ops/s
FilterBenchmark.oldFashionFilters             100000  thrpt   50      1999.032 ±       6.829  ops/s
FilterBenchmark.oldFashionFilters            1000000  thrpt   50       200.564 ±       1.695  ops/s

Java 12

# Run complete. Total time: 04:36:20
    
Benchmark                                (arraySize)   Mode  Cnt         Score         Error  Units
FilterBenchmark.complexFilter                     10  thrpt   50  10338525.553 ? 1677693.433  ops/s
FilterBenchmark.complexFilter                    100  thrpt   50   4381301.188 ?  287299.598  ops/s
FilterBenchmark.complexFilter                   1000  thrpt   50    607572.430 ?    9367.026  ops/s
FilterBenchmark.complexFilter                  10000  thrpt   50     30643.286 ?     472.033  ops/s
FilterBenchmark.complexFilter                 100000  thrpt   50      1450.341 ?       3.730  ops/s
FilterBenchmark.complexFilter                1000000  thrpt   50       138.996 ?       2.052  ops/s
FilterBenchmark.complexFilterParallel             10  thrpt   50     21289.444 ?     183.245  ops/s
FilterBenchmark.complexFilterParallel            100  thrpt   50     20105.239 ?     124.759  ops/s
FilterBenchmark.complexFilterParallel           1000  thrpt   50     19418.830 ?     141.664  ops/s
FilterBenchmark.complexFilterParallel          10000  thrpt   50     13874.585 ?     104.418  ops/s
FilterBenchmark.complexFilterParallel         100000  thrpt   50      5334.947 ?      25.452  ops/s
FilterBenchmark.complexFilterParallel        1000000  thrpt   50       781.046 ?       9.687  ops/s
FilterBenchmark.multipleFilters                   10  thrpt   50   5460308.048 ?  478157.935  ops/s
FilterBenchmark.multipleFilters                  100  thrpt   50   2227583.836 ?  113078.932  ops/s
FilterBenchmark.multipleFilters                 1000  thrpt   50    287157.190 ?    1114.346  ops/s
FilterBenchmark.multipleFilters                10000  thrpt   50     16268.016 ?     704.735  ops/s
FilterBenchmark.multipleFilters               100000  thrpt   50      1531.516 ?       2.729  ops/s
FilterBenchmark.multipleFilters              1000000  thrpt   50       123.881 ?       1.525  ops/s
FilterBenchmark.multipleFiltersParallel           10  thrpt   50     20403.993 ?     147.247  ops/s
FilterBenchmark.multipleFiltersParallel          100  thrpt   50     19426.222 ?      96.979  ops/s
FilterBenchmark.multipleFiltersParallel         1000  thrpt   50     17692.433 ?      67.606  ops/s
FilterBenchmark.multipleFiltersParallel        10000  thrpt   50     12108.482 ?      34.500  ops/s
FilterBenchmark.multipleFiltersParallel       100000  thrpt   50      3782.756 ?      22.044  ops/s
FilterBenchmark.multipleFiltersParallel      1000000  thrpt   50       589.972 ?      71.448  ops/s
FilterBenchmark.oldFashionFilters                 10  thrpt   50  41024334.062 ? 1374663.440  ops/s
FilterBenchmark.oldFashionFilters                100  thrpt   50   6011852.027 ?  246202.642  ops/s
FilterBenchmark.oldFashionFilters               1000  thrpt   50    553243.594 ?    2217.912  ops/s
FilterBenchmark.oldFashionFilters              10000  thrpt   50     29188.753 ?     580.958  ops/s
FilterBenchmark.oldFashionFilters             100000  thrpt   50      2061.738 ?       8.456  ops/s
FilterBenchmark.oldFashionFilters            1000000  thrpt   50       196.105 ?       3.203  ops/s

3
重复很明显,垃圾回收不是;在我看来,这并没有回答问题。我希望Alexey能够呈现他的发现。 - Eugene
1
是的,我同意你的看法@Eugene,我已经在评论中向Alexey询问了解释。我希望他能抽出时间提供更多相关信息。 - Serge
你能解释其中的显而易见之处吗?我的意思是,这还是回归问题吧?由于这次没有进行充分热身,那么使用12是否会更慢一些呢?(但那样的话它应该已经热身了吧?) - eckes

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接