On Sat, 29 Jan 2022 16:31:43 GMT, Tagir F. Valeev <tval...@openjdk.org> wrote:

> See the bug description for details.
> 
> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and 
> report artificial estimatedSize(), much bigger than the real one. This will 
> allow AbstractSpliterator and IteratorSpliterator to produce prefix whose 
> size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), 
> and this will enable further splitting of the prefix. This change will 
> drastically improve parallel streaming for affected streams of size <= 1024 
> and significantly improve for streams of size 1025..20000. The cost is 
> higher-grained splitting for huge streams of unknown size. This might add a 
> minor overhead for such scenarios which, I believe, is completely tolerable.
> 
> No public API changes are necessary, sequential processing should not be 
> affected, except an extra field in ArraySpliterator which increases a 
> footprint by 8 bytes.
> 
> I added a simple test using an artificial collector to ensure that at least 
> two non-empty parts are created when parallelizing Stream.iterate source. 
> More testing ideas are welcome.

This pull request has now been integrated.

Changeset: 4cc8eccf
Author:    Tagir F. Valeev <tval...@openjdk.org>
URL:       
https://git.openjdk.java.net/jdk/commit/4cc8eccfcadf5d3edc31809ead2dd6554c7cca4b
Stats:     212 lines in 3 files changed: 178 ins; 0 del; 34 mod

8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator 
when size is unknown

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/7279

Reply via email to