java8stream性能
最近,我提出了一些有关Java 8流性能的基准测试结果。 你们和gal足够有兴趣留下一些想法,还有哪些可以介绍。
这就是我所做的,这里是结果。
总览
最后一篇文章的序言也适用于此。 阅读它,以找出所有数字为何撒谎,我如何提出这些数字以及如何复制它们。
我在GitHub上的代码中添加了一个新类CommentOperationsBenchmark
,其中包括本文中讨论的基准。 我还更新了Google电子表格,以包括新的数字。
public int array_max_forWithException() {
int m = Integer.MIN_VALUE;
try {
for (int i = 0; ; i++)
if (intArray[i] > m)
m = intArray[i];
} catch (ArrayIndexOutOfBoundsException ex) {
return m;
}
}
也许他们应该停止,因为它看起来并不能改善性能:
看来,用于打破循环的机制没有可衡量的影响。 这是有道理的,因为展开循环可以避免大多数比较,并且引发异常的代价在几微秒的范围内 ,因此比此处发生的情况小几个数量级。
这是假设编译器确实有更多技巧。 也许它在更深层次上理解循环,并且JIT将这两种方法编译为相同的指令。
附带说明一下:看看在循环之后array_max_forWithException
如何没有return
语句?
事实证明Java编译器可以识别简单的无限循环 。 哇! 因此,它知道具有有限计算的每个代码路径都会返回,而不关心无限的代码路径。
归结为以下内容:
public int infiniteLoop() {
for(;;);
}
您永远不会停止学习……
这是指所有测试都是在数组或列表上运行的,这些数组或列表的元素等于结构中的索引,即[0, 1, 2, ..., n-1]
。 因此,找到最大值确实需要n
分配。
那找到一个只需要分配一次的最小值呢?
不,没有区别。 我的猜测是,由于流水线作业,分配实际上是免费的。
关于拳击有两条评论。
int[]
, Integer[]
和List<Integer>
:
我们可以清楚地看到,运行时的主要指标是数据结构是包含基元还是对象。 但是将Integer数组包装到列表中会导致额外的速度降低。 Yann Le Tallec也对拳击发表了评论:
intList.stream()。max(Math :: max); 造成不必要的拆箱。 intList.stream()。mapToInt(x-> x).max(); 速度大约是阵列版本的两倍。
此声明与我们在上一篇文章中得出的结论一致:尽快对流进行拆箱可提高性能。
只是再次检查:
这似乎证实了这一说法。 但是结果看起来非常可疑,因为错误很大。 使用不同的设置反复运行这些基准测试显示了一种模式:
- 存在两种性能水平,一种是〜3.8 ns / op,一种是〜7.5 ns / op。
- 未装箱的流只表现更好。
- 盒装流的单个迭代通常在这两个级别中的任何一个上运行,但很少在其他时间进行。
- 大多数情况下,行为只会在分支之间改变(即从一组迭代到下一组)。
这一切都令人怀疑我的测试设置存在问题。 听到任何想法的人,我会很有趣。
Redditor robi2106在他的“ i5-4310 @ 2Ghz w 8GB DDR2”上运行了500,000个元素的套件。 我将结果添加到电子表格中 。
很难从数据中得出结论。 Robi指出“在这2.5个小时中我也没有停止使用我的系统”,这也许可以解释巨大的误差范围。 他们的平均年龄是我的23倍,平均是我的168倍。 (另一方面,我也继续使用我的系统,但是负载很低。)
如果斜视一下,您可以推断出i5-4310在简单计算上会稍快一些,但在更复杂的计算上会落后一些。 考虑到i7-4800的内核数量是原来的两倍,通常可以达到并行性能。
我仍然没有尝试使用Scala,也不想为一个基准测试而努力。 也许经验更丰富或更鲜美的人可以尝试一下?
在解释这些数字时,请记住,这些迭代执行了非常便宜的操作。 上次我们发现,已经很简单的算术运算会导致足够的CPU负载,几乎完全抵消了迭代机制的差异 。 因此,像往常一样,不要过早优化!
总之,我会说:没有新发现。 但是,我很喜欢与您讨论您的想法,如果您有更多想法,请发表评论。 甚至更好的是,自己尝试一下并发布结果。
该帖子最初发布在codefx.org上 。
翻译自: https://jaxenter.com/java-stream-performance-your-ideas-121190.html
java8stream性能