default random access list spliterator

[Paul Sandoz]

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.hixson at 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