Performance of default Spliterators

[Raab, Donald [Tech]]

Any RandomAccess Lists not currently in the JDK repository.

For example:

http://docs.guava-libraries.googlecode.com/git-history/release/javadoc/com/google/common/collect/ImmutableList.html

GS Collections has quite a few as well.  I'd like for parallel streams to be performant when used there.  :-)

> -----Original Message-----
> From: Brian Goetz [mailto:brian.goetz at oracle.com]
> Sent: Friday, May 10, 2013 1:54 AM
> To: Raab, Donald [Tech]
> Cc: lambda-libs-spec-experts at openjdk.java.net
> Subject: Re: Performance of default Spliterators
> 
> Entirely reasonable.  Actually, might not even need much implementing.
> You could do:
> 
>    return IntStream.range(0, size()).map(List::get);
> 
> (if you could tolerate the early binding to size.)
> 
> The efficacy question is: what List implementations implement RA that
> don't already have their own specialized spliterator?
> 
> On 5/9/2013 7:53 PM, Raab, Donald [Tech] 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);
> >      }
> > RandomAccessSpliterator would of course need to be implemented.
> > Thoughts?  Make sense?  Already planned?