aro*_*ech 12 java lambda java-8 java-stream
for在大多数情况下,Java 8流允许的代码比旧式循环更具可读性.但是,根据我自己的经验和我所读到的内容,使用流而不是for循环可能会导致性能损失(或偶尔会有改进),有时难以预测.
在大型项目中,为每个循环编写基准测试似乎不可行,因此在决定是否for用流替换循环时,关键因素是什么(例如,预期的集合大小,预期的值删除百分比)过滤,迭代操作的复杂性,减少或聚合的类型等等,它们可能表明将导致的性能变化？
注意:这是我之前的问题的缩小,因为过于宽泛而关闭(并且并行流的各个方面在另一个SO问题中得到了很好的覆盖),所以让我们将其限制为顺序流.
Hol*_*ger 23
它不仅"为每个循环编写基准测试都不可行",而且反效果.特定的,特定于应用程序的循环在被置于微基准测试中时可能完全不同.
对于实际应用,标准优化规则适用:不要这样做.只需编写更具可读性的内容,并且只有在出现性能问题时,才能对整个应用程序进行概要分析,以检查特定循环或流是否真正成为瓶颈.只有在这种情况下,您可以尝试在特定瓶颈的两个习语之间切换,看看它是否有所作为.
在大多数情况下,它不会.如果存在真正的性能问题,它将源于操作类型,例如执行具有O(n²)时间复杂度的嵌套迭代等.此类问题不依赖于您是使用a Stream还是for循环以及这两者之间的微小性能差异成语不会改变代码的缩放方式.
有没有存在很大的一般速度的差异streams和loops自身的优势,/缺点是具体问题.您是选择其中一个应该(主要)取决于代码的可读性.对于某些性能比较,请参阅Benchmark1和Benchmark2,您可以在其中看到Brian Goetz对其中一个答案的评论:
关于表现的结论虽然有效,却被夸大了.在很多情况下,流代码比迭代代码更快,主要是因为流的每元素访问成本比使用普通迭代器更便宜.在许多情况下,流版本内联到与手写版本相同的内容.当然,魔鬼在于细节; 任何给定的代码位可能表现不同.
除此之外,请确保在您进行基准测试时使用JMH.
| 归档时间： |
|
| 查看次数： |
1113 次 |
| 最近记录： |