Custom spliterator for Collections.nCopies(n, obj).stream()

[Paul Sandoz]

Hi Tagir,

I would agree with you out about changing to use unordered() except that it is a List that is returned, whose Spliterator is specified to report ORDERED.

I don’t particular want to add a special spliterator for this case to avoid some profile pollution. Will it not just push the pollution further down the road to Spliterator.forEachRemaining? or to within other code?

Alas i think profile pollution is current fact of JDK life when inverting control with lambdas. What we really require is a better way to specialise the hot loops.

Paul.

On 28 Jul 2015, at 10:37, Tagir F. Valeev <amaembo at gmail.com> wrote:

> Hello!
> 
> Current implementation of Collections.nCopies().stream() is as
> follows:
> 
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/f160dec9a350/src/java.base/share/classes/java/util/Collections.java#l5066
> 
> public Stream<E> stream() {
>    return IntStream.range(0, n).mapToObj(i -> element);
> }
> 
> @Override
> public Stream<E> parallelStream() {
>    return IntStream.range(0, n).parallel().mapToObj(i -> element);
> }
> 
> The problem is that it adds a lambda expression to the
> RangeIntSpliterator type profile which can be polluted by some other
> code and vice versa: using nCopies().stream() may pollute the type
> profile for other code making it slower.
> 
> Another thing which is missing in current implementation is unordered
> mode. This collection is unordered by nature, its stream is similar to
> Stream.generate(), so to my opinion it should be unordered which may
> improve the parallel reduction in some cases.
> 
> This can be improved by introducing the custom spliterator class which
> is quite simple:
> https://gist.github.com/amaembo/62f3efee9923b1468e86
> 
> On pre-polluted type profile with simple mapping and reduction using
> custom spliterator is about 25-30% faster in both parallel and
> sequential cases as benchmarking shows (performed on 4-core cpu).
> 
> What do you think?
> 
> With best regards,
> Tagir Valeev.
>