有没有Java 8流和Guava可迭代对象之间的基准测试比较？

Question

我在Java 8上使用Guava感到非常满意 - 在将顺序代码迁移到Streams时是否存在任何性能优势或陷阱？

- Duncan McGregor

---

嗯，你有使用案例吗？如果有的话，你可以尝试进行微基准测试。 - fge

JIT已经在Java 8中针对流进行了显著的优化。即使您不更改代码，也应该使用Java 8 JVM。这样做可以以更小的努力获得更大的差异。 - Peter Lawrey

我可以对我的用例进行基准测试，但我更愿意看到一些研究来帮助决定在我的常规代码中是默认使用流还是可迭代对象。 - Duncan McGregor

请注意，Guava团队对Java 8流的设计做出了贡献，我们普遍认为它们优于我们的东西。进步的步伐值得欢呼！ - Kevin Bourrillion

Answer 1

我已经开始在GitHub上开展一个项目来尝试这个。

对于流的标识映射，Java HotSpot(TM) 64位服务器VM（版本25.25-b02，混合模式），在2014 MacBookAir 1.7Ghz i7上进行的初始结果令人惊讶，代码版本为https://github.com/dmcg/iterables-v-streams#ea8498ee0627fc59834001a837fa92fba4bcf47ebcf47e

实验选择： 基准方法：[guava，iterate，streams] 工具：[allocation，runtime] 用户参数：{} 虚拟机：[默认] 选择类型：完全笛卡尔积

此选择产生6个实验。 试验报告（1/6）： 实验 {instrument=allocation，benchmarkMethod=iterate，vm=default，parameters={}} 结果： 字节(B)：min=4072.00，1st qu.=4072.00，median=4072.00，mean=4072.00，3rd qu.=4072.00，max=4072.00 对象数：min=3.00，1st qu.=3.00，median=3.00，mean=3.00，3rd qu.=3.00，max=3.00 试验报告（2/6）： 实验 {instrument=allocation，benchmarkMethod=guava，vm=default，parameters={}} 结果： 字节(B)：min=15104.00，1st qu.=15104.00，median=15104.00，mean=15104.00，3rd qu.=15104.00，max=15104.00 对象数：min=17.00，1st qu.=17.00，median=17.00，mean=17.00，3rd qu.=17.00，max=17.00 试验报告（3/6）： 实验 {instrument=allocation，benchmarkMethod=streams，vm=default，parameters={}} 结果： 字节(B)：min=15272.00，1st qu.=15272.00，median=15272.00，mean=15527.64，3rd qu.=15432.00，max=17252.80 对象数：min=20.00，1st qu.=20.00，median=20.00，mean=25.00，3rd qu.=26.00，max=53.00 试验报告（4/6）： 实验 {instrument=runtime，benchmarkMethod=guava，vm=default，parameters={}} 结果： 运行时间(ns)：min=13365.32，1st qu.=13660.61，median=13802.51，mean=13961.91，3rd qu.=14445.46，max=14715.34 试验报告（5/6）： 实验 {instrument=runtime，benchmarkMethod=iterate，vm=default，parameters={}} 结果： 运行时间(ns)：min=9952.47，1st qu.=10892.64，median=11372.35，mean=11243.07，3rd qu.=11785.48，max=12024.76 试验报告（6/6）： 实验 {instrument=runtime，benchmarkMethod=streams，vm=default，parameters={}} 结果： 运行时间(ns)：min=10527.26，1st qu.=11051.70，median=11747.29，mean=11631.15，3rd qu.=12205.97，max=12581.39 从以下收集了81个测量值： 2个工具 2个虚拟机 3个基准

执行完成：1.188分钟。 结果已上传。在此处查看：https://microbenchmarks.appspot.com/runs/d2c7f83b-2cfa-4217-ab0b-e8d506eaa85c

我还在努力理解Google的卡尺，但它似乎表明流比Guava更快，而且比直接使用for循环慢不了多少。

- Duncan McGregor

---

Caliper存在正确性问题，例如由于循环展开。JMH是首选的基准测试工具。 - Ben Manes

该死，我以为使用Google是安全的。不过我猜在这里展开循环不会有太大的区别。 - Duncan McGregor

这是其中一个缺陷，包括死代码消除（因为你没有返回值）。Caliper基于Bloch的性能焦虑、Click的基准测试艺术的建议以及来自Android团队的反馈。没有任何参与者是VM工程师，它模仿了一个基本的测试框架，对于复杂的场景（如线程）毫无用处。它是博客文章和回归检查的更好默认值，但对于严肃的工作（例如Guava的大多数都是无意义的）不可用。 - Ben Manes

我们非常需要确凿的数据，但迄今为止还没有人能够提供。另一件事是Caliper的实际测量策略是可插拔的，而当前默认的策略只是当前的默认值。它本来可以被替换，但是却选择了创建一个完全独立的框架。 - Kevin Bourrillion

@Xaerxess 设计一个公平的单线程基准测试来查找问题比诊断损坏的基准测试要困难得多。我对&和&&进行了基准测试，结果有不同的获胜者。我使用C++作为裁决者，与JMH达成一致。 - Ben Manes