To Stream.slice(fromInclusive, toExclusive) or Stream.slice(toSkip, limit) that is the question

Doug Lea dl at
Fri Oct 11 07:31:18 PDT 2013

On 10/11/2013 10:18 AM, Brian Goetz wrote:

> Several have pointed out that it is surprising that .skip(n).limit(k) is
> inefficient enough to want a fusing.  Of course, in the sequential case, its
> fine.  But because skip/limit are constrained to operate in encounter order, in
> the worst case (non-SIZED+SUBSIZED, non-UNORDERED), we have to buffer.  Doing
> two rounds of buffering would suck twice -- and this was the primary motivation
> for a fused operation.
> So I think there are two sensible choices here:
>   - slice(toSkip, toLimit)
>   - drop slice entirely
> The cost of the latter is that those who need it in parallel in the unpleasant
> cases are even more likely to have to retreat to sequential.

In other words: If running sequentially, skip(n).limit(k) costs almost
nothing more than slice. And the same nearly holds for cases where
people do an intrinsically sequential operation in parallel
(i.e., using either skip or limit on ordered data) --
you get about twice the terrible cost of either skip or limit.

Seems like a fine idea to just drop it.


More information about the lambda-libs-spec-experts mailing list