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

[Brian Goetz]

Further argument for dropping: while we don't do implicit op fusion now 
(an earlier version had this, but we dropped it as it was getting in the 
way of some more valuable things), now that the implementation has 
stabilized, it looks like the current implementation is pretty amenable 
to pairwise op fusion.  So it seems likely there's a path to having the 
implementation just turn skip+limit into the more efficient version.

On 10/11/2013 10:31 AM, Doug Lea wrote:
> 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.
>
> -Doug
>
>