使用链式操作快速降低流吞吐量？

Question

我希望像limit() 这样的简单中间流操作的开销很小。但这些示例之间的吞吐量差异实际上是显着的：

final long MAX = 5_000_000_000L;

LongStream.rangeClosed(0, MAX)
          .count();
// throughput: 1.7 bn values/second


LongStream.rangeClosed(0, MAX)
          .limit(MAX)
          .count();
// throughput: 780m values/second

LongStream.rangeClosed(0, MAX)
          .limit(MAX)
          .limit(MAX)
          .count();
// throughput: 130m values/second

LongStream.rangeClosed(0, MAX)
          .limit(MAX)
          .limit(MAX)
          .limit(MAX)
          .count();
// throughput: 65m values/second

我很好奇：吞吐量快速下降的原因是什么？它与链式流操作或我的测试设置是否一致？ （我目前没有用过JMH，只是用秒表设置了一个快速实验）

Answer 1

limit 将导致由流组成一个 slice，并带有一个 split iterator（用于并行操作）。一言以蔽之：低效。此处无操作的开销很大。而且连续两次limit 调用导致两个切片是一种耻辱。

你应该看看IntStream.limit的实现。

由于 Streams 仍然相对较新，因此优化应该放在最后；当生产代码存在时。限制3次似乎有点牵强。

Answer 2

这是 Stream API 中的一个未实现的实现（不知道如何调用它）。

在第一个示例中，您知道 count 没有实际计数 - 没有可能清除名为 SIZED 的内部标志的 filter（例如）操作。如果你改变它并检查它实际上有点有趣：

System.out.println(
            LongStream.rangeClosed(0, Long.MAX_VALUE)
                    .spliterator()
                    .hasCharacteristics(Spliterator.SIZED)); // reports false

System.out.println(
            LongStream.rangeClosed(0, Long.MAX_VALUE - 1) // -1 here
                    .spliterator()
                    .hasCharacteristics(Spliterator.SIZED)); // reports true

而limit - 即使没有基本 (AFAIK) 限制，也不会引入 SIZED 标志：

System.out.println(LongStream.rangeClosed(0, MAX)
            .limit(MAX)
            .spliterator()
            .hasCharacteristics(Spliterator.SIZED)); // reports false

既然你到处都算数，Stream API 内部不知道流是否为SIZED，它只是算数；而如果流是SIZED - 报告计数会很好，即时。

当您添加limit 几次时，您只会变得更糟，因为它必须每次都限制这些限制。

以 java-9 为例，情况有所改进：

System.out.println(LongStream.rangeClosed(0, MAX)
            .map(x -> {
                System.out.println(x);
                return x;
            })
            .count());

在这种情况下，map 根本不计算，因为不需要它 - 没有中间操作会更改流的大小。

理论上，Stream API 可能会看到您是 limiting 并且 1) 引入 SIZED 标志 2) 看到您有多次调用 limit 并且可能只使用最后一个。 目前这个还没有做，但是这个范围很有限，有多少人会这样滥用limit呢？所以不要指望这部分很快会有任何改进。