Java parallel streams: 3.6x slower on 1,000 items, 6x faster on 50 million
When are Java parallel streams slower than sequential streams?
On an 8-core machine with JDK 17, summing 1,000 elements took 0.030 ms sequentially and 0.109 ms in parallel (3.6x slower), 100,000 elements was a tie, and 50 million elements took 65.5 ms sequentially vs 10.6 ms in parallel (6x faster).
Results
| n = 1,000 | sequential 0.030 ms | parallel 0.109 ms |
|---|---|
| n = 100,000 | sequential 0.121 ms | parallel 0.108 ms |
| n = 50,000,000 | sequential 65.5 ms | parallel 10.6 ms |
How it was measured
IntStream.range(0, n).mapToLong(i -> i*i % 7).sum(), best of 30 rounds, 8 cores.
IntStream.range(0, n).parallel().mapToLong(i -> (long) i * i % 7).sum();Why
Parallel streams split the work and merge results across the common fork-join pool. That overhead only pays off when there is enough CPU-bound work.
When this does not apply
I/O-bound work and shared mutable state do not benefit. Results depend on core count.
Environment
MacBook Air (Apple silicon, 8 cores), macOS, JDK 17. Measured 2026-10-12.
Source: shorts/demo-ticket/java/Par.java in my content-engine repository. Treat any single run as a direction; re-run it on your hardware.
Related
By Josué Barros, senior software engineer (full-stack, data and AI).