On 06/04/2015 10:34 AM, Paul Sandoz wrote:
On Jun 4, 2015, at 10:09 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
On 06/04/2015 09:37 AM, Paul Sandoz wrote:
On Jun 4, 2015, at 9:04 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
Thinking a little more about dropWhile(),
it can be written using filter() more or less like this:
default Stream<T> dropWhile(Predicate<? super T> predicate) {
return filter(new Predicate<>() {
private boolean noDropAnymore;
public boolean test(T t) {
return noDropAnymore || (noDropAnymore = !predicate.test(t));
}
});
}
and i maybe wrong but implementing dropWhile with an op is not better than that
in term of perf so for me dropWhile() doesn't pull its own weight.
Try running that in parallel.
And try with an ordered parallel stream and see if it produces the same results
as that produced sequentially.
It won't, you have to know how the splitting is done.
I'm not sure it's a good idea if you want good perf, the cost of checking a
volatile flag inside the loop for each thread (I don't see how to have
something more lightweight) will cost more than just keeping the stream
sequential, no ?
You are imposing a restriction that this should *only* run sequentially.
Stateful ops such as take/drop and limit/skip have to be used with care when
executed in parallel. That does not mean we should rule it out (however, it's
reasonable for default implementations of take/drop to not split, which is what
is currently implemented more so for code-sharing).
In general parallel streams should be used with care, we keep saying don't
sprinkle parallel on your streams like pixie dust and expect it to work magic
:-)
Ok.
(Stream.parallel() affects the whole pipeline, so it's not possible to
implement the default with sequential().filter(p) where p is a stateful
predicate.)
it's possible,
the default should return a proxy in front of the result of
sequential().filter(p) that return this if parallel() is called.
A sequential slight of hand. Ugh :-)
Paul.
Rémi
