Stream.unordered()

[Mike Duigou]

> <p>Parallel evaluation of downstream operations

I would remove "Parallel". Not because I have specific examples of where a sequential implementation might do something out of order but because it seems like over specification.

Mike

On Nov 5 2012, at 08:22 , Paul Sandoz wrote:

> Grrr. attachments (even just textual attachments of a reasonable size) are removed...
> 
> Paul.
> 
> On Nov 5, 2012, at 4:49 PM, Paul Sandoz <Paul.Sandoz at oracle.com> wrote:
> 
>> HI,
>> 
>> See attached for a patch that adds Stream.unordered().
>> 
>> This method will clear the encounter order flag. When this flag is cleared certain downstream stateful operations evaluated in parallel may choose to apply algorithms that do not preserve encounter order.
>> 
>> Such algorithms may be more efficient than order preserving algorithms, although i would say that one should not presume this to be a general assumption and has to be taken on a case by case basis.
>> 
>> One such example is obtaining unique elements. 
>> 
>> When encounter order is to be preserved it might be required to merge the linked hash sets produced at the leaves of the computation tree. That merging has a cost, i suspect it is rather tricky to write a parallel set merge algorithm, so a naive implementation would just take the set on the left hand side of a tree and merge with set on the right hand side using Set.addAll.
>> 
>> When encounter order need not be preserved one can stuff elements as and when they are produced into a shared ConcurrentHashMap.
>> 
>> Paul.