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.
> 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
:-)
>>
>> (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.
