Performance of default Spliterators

[Paul Sandoz]

On May 10, 2013, at 1:53 AM, "Raab, Donald [Tech]" <Donald.Raab at gs.com> wrote:

> Apologies if this was already discussed, thought about, planned or in progress.
> 
> Right now in the build I am using (about a week old) spliterator returns the following:
> 
>    default Spliterator<E> spliterator() {
>        return Spliterators.spliterator(this, Spliterator.ORDERED);
>    }
> 
> For ArrayList this is overridden to return an ArrayListSpliterator.  I think there should be an instance of check in spliterator to check for RandomAccess so performance is better for other RandomAccess lists that might be implemented in other libraries.  So the following code would need to be changed from this:
> 
>    public static <T> Spliterator<T> spliterator(Collection<? extends T> c,
>                                                 int additionalCharacteristics) {
>        return new IteratorSpliterator<>(Objects.requireNonNull(c),
>                                         additionalCharacteristics);
>    }
> 
> To this:
> 
>    public static <T> Spliterator<T> spliterator(Collection<? extends T> c,
>                                                 int additionalCharacteristics) {
>        if (c instanceof RandomAccess)
>        return new RandomAccessSpliterator<>(c, additionalCharacteristics);
> 
>        return new IteratorSpliterator<>(Objects.requireNonNull(c),
>                                         additionalCharacteristics);
>    }
> 

Perhaps it would be better to change the default spliterator() implementation in List, since Collection & RandomAccess is not very useful:

    @Override
    default Spliterator<E> spliterator() {
        if (this instanceof RandomAccess) {
            return new RandomAccessListSpliterator(this);    
        } else {
            return Spliterators.spliterator(this, Spliterator.ORDERED);
        }
    }


> RandomAccessSpliterator would of course need to be implemented.
> 
> Thoughts?  Make sense?  Already planned?
> 

Seems OK to me.

Paul.