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 <amae...@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. >
