Add a comment


Re: The effects of programming with Java 8 Streams on algorithm performance

This is theory. It is true if running the test programs on an otherwise idling computer. But in real life, this never appends. You say that it is legal to use parallel streams in J2EE. It may be legal, but it is not wise.

By default, parallel streams will use the same ForkJoinPool for all parallel streams. Doing otherwise would be inefficient, since it could result in many clients running parallel streams at the same time in many ForkJoinPool.

Using a single common ForkJoinPool, if a parallel stream result in several very long subtasks, it will block other parallel streams.

In a non J2EE environment, one may be tempted to use one ForkJoinPool for each parallel stream. This will result in much more threads running in parallel that there are processors on the computer, leading to a performance decrease.

Even worst, the programmer might very well see an performance increase in tests (were each ForkJoinPool is run in isolation) and a decrease in production.

Parallel streams are very good at handling tasks with long waits, such as what we can see in many examples by Java 8 evangelists (for example connecting to a server to get stock values). However, this is not parallel processing, but concurrent processing, since although it may run on multiple threads, we get nearly the same increase in performance if using a single thread.

The real interest of Streams as you noted, is that they allow using the functional paradigm because they are lazily evaluated (only when using a terminal operation). Parallel streams are, at best, a toy.

Re: The effects of programming with Java 8 Streams on algorithm performance

HTML : b, strong, i, em, blockquote, br, p, pre, a href="", ul, ol, li, sub, sup
E-mail address
Remember me Yes  No 

E-mail addresses are not publicly displayed, so please only leave your e-mail address if you would like to be notified when new comments are added to this blog entry (you can opt-out later).