Zipping Steams...

[Brent Walker]

Ah yes the curse of the megamorphic.  Ok, I went back to the consumer style
as you had it but with only 1 member variable (instead of two).  After the
first tryAdvance() you can remember the left value in a local variable so
the accept function just becomes:

    @Override
    public void accept(final Object x) {
      mCache = x;
    }

and tryAdvance():

    @Override
    @SuppressWarnings("unchecked")
    public boolean tryAdvance(Consumer<? super W> action) {
      if (mLeftSpliter.tryAdvance(this)) {
        final T leftElem = (T) mCache;

        if (mRightSpliter.tryAdvance(this)) {
          final U rightElem = (U) mCache;

          action.accept(mZipper.apply(leftElem, rightElem));
          return true;
        }
      }
      return false;
    }

Brent



On Mon, Jan 13, 2014 at 9:33 PM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> On Jan 13, 2014, at 7:25 PM, Brent Walker <brenthwalker at gmail.com> wrote:
> > Thank you for pointing out the error in our ways.  Here is your code
> updated so that it compiles with the current state of the API.
>  (StreamSupport.parallelStream() does not exist anymore, Streams.NONE also
> not there).
>
> Yeah, you can tell i copied that from some cache and neglected to update
> it :-)
>
>
> > Since Streams.NONE was not there, I modified tryAdvance() to use the
> continuation passing style we had in our solution and got rid of the
> accept(Object) function.  This avoids all the casting, and we can delete
> Objects "a" and "b" from the Spliterator (which now does not have to be a
> Consumer<>).
>
> Although that is likely to be not as efficient as reusing the Spliterator
> instance as the Consumer, which avoids two capturing lambdas per-element
> and has less layering.
>
>
> > Hopefully hotspot can see throw all the code threading and inline
> everything.
> >
>
> Perhaps. Hotspot inlining is impressive but lambdas are pushing it the
> limit and there is definitely room for improvement especially in cases such
> as tryAdvance or forEachRemaining where call sites can easily go
> megamorphic. Hence in part to currently put up with the ugliness of casts
> etc.
>
>
> > Don't you have a place where examples of code can be placed in the jdk?
>
> Nothing official, it would be in the JDK otherwise :-)
>
> Cheekiness aside, i think a github project would be fine, and i would
> happy to help commit and maintain examples of stuff that nearly but not
> quite made the cut in the JDK and other informative examples. Wanna create
> one?
>
> Paul.
>
>
>
>