Did you check to see if there is an advantage in speed if you specialize
`invokeParallelOperation` in such a custom scheduler? Even if we allocate
the root, we could win there (alternatively, we could reuse the same
instance of the root in a thread local, not sure if that would be faster).
Seems to me an aggregate will always box at least the result when using the
`Scheduler.WorkstealingTree`.


On Mon, Nov 25, 2013 at 2:06 PM, DarkDimius <notifications@github.com>wrote:

> In src/main/scala/scala/collection/par/Scheduler.scala:
>
> > @@ -180,6 +198,16 @@ object Scheduler {
> >      }
> >    }
> >
> > +  object Sequential extends WorkstealingTree {
>
> Ref also needs to be allocated, as we sometimes have not-trivial logic in
> beforeWorkOn(ref, node)(needer for reducable)
> and afterCreateRoot(root: Ref[T, ProgressStatus])(currently used by concs,
> but the same way how it's used for reducable).
>
> This negates any performance advantage of having separate
> invokeParallelOperation, but incurs maintaining cost.
> If you insist, i can do it. But It still seems like something it will make
> maintaining harder(we'll need to always make sure that we don't break
> sequential version), while providing no advantages.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/scala-blitz/scala-blitz/pull/14/files#r7889913>
> .
>