In what application niche is parallelStream from Java useful?

Question

I'm trying to identify a class of Java applications that could benefit from use of parallelStream API introduced in Java 8.

I'm aware of the numerous caveats of the API described in other SO posts :

• Shared fork/join pool, with non trivial starting time, and some potential issues with contention in the pool
• Uncontrolled use of system resources in a way that makes using this sort of code on a server (that already has a multi-task policy) might actually be a bad idea
• ... there are other criticisms mostly related to performance

Still, the API offers to make use of modern multicore machines with code that is not very intrusive provided Stream API is already used, so no hassle multi-threading at low development cost. I would therefore still like to think it can be useful in some scenarios.

I'm thinking the application context thus has to be something like :

1. my application is currently sequential
2. there is a response time issue, in terms of wall clock time, e.g. the user clicked a GUI button and is waiting for reply
3. the application is running on client machines, where most of the time we can expect to have some available CPU cores, not on a server where resources are already contended
4. my development team does not have the manpower/skills to develop their own task allocation/threading mechanism, so they would not go for parallelism unless they can do it easily using this API

I searched on github, but it's quite hard to find relevant examples of parallelStream usage that are not exercises or textbook examples (I'd welcome links to some usage in midsize+ projects of the API).

So which kind of applications were the Java language developers targetting with this API ?

Would you agree with the above requirements on the application context for the API to be useful ?

Answer 1

This looks like a nice explanation of cases of where and why. https://computing.llnl.gov/tutorials/parallel_comp/#WhyUse I personally see no interesting cases in user centered web applications.

The fork/join Framework is a really cool low level api. Many other higher level frameworks use it under the hood very successfuly. I've used it for test data generation. Cache bootstraping. Data processing etc... In many cases you get a really good boost of performance in others its just unnecessary overhead.

Answer 2

A similar question is asked in Should I always use a parallel stream when possible? Note the second answer is given by Brian Goetz, a Java language architect at Oracle who was involved in the design of the Stream API, so his answer may be considered authoritative.

Top answers are quick to point out that parallel streams include additional overhead necessary for coordination and thus will only increase performance in scenarios where the amount of individual processing per stream is significant enough that the gain from parallel processing overcomes that initial overhead.

Unsurprisingly, as with any question of performance, the advice is to measure rather than guess. Start with a sequential stream, and if you have a large number of elements each requiring complex computation, measure the performance difference of switching to parallel streams.

Additional guidelines, such as those listed in the OP, may be helpful; but people are notoriously bad at identifying performance bottlenecks, so any guidelines are likely to fail eventually in the face of actual measurements.

Answer 3

the application is running on client machines, where most of the time we can expect to have some available CPU cores, not on a server where resources are already contended

This prediction does not have any foundation. Both on desktop and server machines, there could be only your application running or there could be 1,000s of applications running.

There is no "application niche" in which parallel streams are useful. You should use them only if you make sure, either via quantitative or qualitative measuring, that performance is improved, and their disadvantages do not matter too much.

They are easy only if you understand the concepts beneath. They can be applied only to a specific subset of problems.

I would consider using them only if:

• all stream operations are pure functions and therefore do not require synchronization
• the performance is not critical, however a boost would be great (so contention of the shared pool can be tolerated)