Hi Michael, It could, stay tuned for some possible action on this.
This is something we did discuss a while ago [1]. At the time we thought most List implementations would override so did not bother, and admittedly with the frenzy of all other stuff got de-prioritized. But, perhaps we underestimated the integration with existing libraries? To do that we would need to adjust the specification of the default behaviour which would also adjust the fail-fast behaviour as Tagir points out (which may be a reasonable compromise in the case, it should be possible to detect certain co-mod cases) Paul. [1] http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-May/001770.html <http://mail.openjdk.java.net/pipermail/lambda-libs-spec-experts/2013-May/001770.html> > On 7 Mar 2016, at 10:02, Michael Hixson <michael.hix...@gmail.com> wrote: > > The default List.spliterator() is iterator-based. Could this be > improved for random access lists, using List.get(int) to fetch > elements instead of List.iterator()? > > I think it could improve most on Spliterator.trySplit(). The current > implementation allocates a new array for split-off elements. I see > almost twice the throughput from list.parallelStream().forEach(...) > with a custom get(int)-based implementation over the default one. > > For example, instead of this: > > default Spliterator<E> spliterator() { > return Spliterators.spliterator(this, Spliterator.ORDERED); > } > > I'm suggesting something like this: > > default Spliterator<E> spliterator() { > return (this instanceof RandomAccess) > ? Spliterators.randomAccessListSpliterator(this) > : Spliterators.spliterator(this, Spliterator.ORDERED); > } > > where randomAccessListSpliterator is new code that looks a lot like > Spliterators.ArraySpliterator. > > -Michael
