java8stream性能_Java Stream性能–您的想法

java8stream性能

最近，我提出了一些有关Java 8流性能的基准测试结果。 你们和gal足够有兴趣留下一些想法，还有哪些可以介绍。

这就是我所做的，这里是结果。

总览

最后一篇文章的序言也适用于此。 阅读它，以找出所有数字为何撒谎，我如何提出这些数字以及如何复制它们。

我在GitHub上的代码中添加了一个新类CommentOperationsBenchmark ，其中包括本文中讨论的基准。 我还更新了Google电子表格，以包括新的数字。

来自讨论Java 8 Stream Performance的 评论 ，与带有支持数组和list的for循环相比 。

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

您永远不会停止学习……

来自讨论Java 8 Stream Performance的 评论 ，与带有支持数组和list的for循环相比 。

这是指所有测试都是在数组或列表上运行的，这些数组或列表的元素等于结构中的索引，即[0, 1, 2, ..., n-1] 。 因此，找到最大值确实需要n分配。

那找到一个只需要分配一次的最小值呢？

不，没有区别。 我的猜测是，由于流水线作业，分配实际上是免费的。

关于拳击有两条评论。

来自讨论Java 8 Stream Performance的 评论 ，与带有支持数组和list的for循环相比 。

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。
• 未装箱的流只表现更好。
• 盒装流的单个迭代通常在这两个级别中的任何一个上运行，但很少在其他时间进行。
• 大多数情况下，行为只会在分支之间改变（即从一组迭代到下一组）。

这一切都令人怀疑我的测试设置存在问题。 听到任何想法的人，我会很有趣。

更新：

Yann确实有一个想法，并指出了这个有趣的问题和有关StackOverflow的出色答案 。 现在，我最好的猜测是，装箱的流可以在未装箱的水平上运行，但可能会因意外的优化而下降。

Redditor robi2106在他的“ i5-4310 @ 2Ghz w 8GB DDR2”上运行了500,000个元素的套件。 我将结果添加到电子表格中 。

很难从数据中得出结论。 Robi指出“在这2.5个小时中我也没有停止使用我的系统”，这也许可以解释巨大的误差范围。 他们的平均年龄是我的23倍，平均是我的168倍。 （另一方面，我也继续使用我的系统，但是负载很低。）

如果斜视一下，您可以推断出i5-4310在简单计算上会稍快一些，但在更复杂的计算上会落后一些。 考虑到i7-4800的内核数量是原来的两倍，通常可以达到并行性能。

来自讨论Java 8 Stream Performance的 评论 ，与带有支持数组和list的for循环相比 。

我仍然没有尝试使用Scala，也不想为一个基准测试而努力。 也许经验更丰富或更鲜美的人可以尝试一下？

在解释这些数字时，请记住，这些迭代执行了非常便宜的操作。 上次我们发现，已经很简单的算术运算会导致足够的CPU负载，几乎完全抵消了迭代机制的差异 。 因此，像往常一样，不要过早优化！

总之，我会说：没有新发现。 但是，我很喜欢与您讨论您的想法，如果您有更多想法，请发表评论。 甚至更好的是，自己尝试一下并发布结果。

该帖子最初发布在codefx.org上 。

翻译自: https://jaxenter.com/java-stream-performance-your-ideas-121190.html

java8stream性能