Performance Comparison of List.sort() vs Stream.sorted() in Java and Optimization Techniques

Initially an API endpoint took about 8 seconds, which was first blamed on I/O or network latency, but the real cause was a nested loop over two lists performed entirely in memory on a CPU with roughly 44 billion floating‑point operations per second.

When I/O and network are not bottlenecks, such long latency is unusual; the performance issue stemmed from repeatedly sorting a list inside the inner loop.

The article provides pseudocode of the original algorithm and a demo comparing list.sort() with list.stream().sorted() . The test on 10 million elements showed list.sort() took 3601 ms while the stream version took 6503 ms, confirming that the native sort is faster.

Using JMH, the author benchmarked both methods for collection sizes of 100, 10 000 and 100 000, and the results consistently favored list.sort() , illustrating a clear performance gap.

Further, the article examines sorting on computed columns. Code examples reveal that a comparator performing division (e.g., e / divisor ) is executed hundreds of millions of times, dramatically increasing cost. Pre‑computing the values before sorting eliminates this overhead.

The impact of BigDecimal arithmetic is also measured. Dividing integers takes about 101 ms, whereas dividing BigDecimal values takes roughly 497 ms (or much more without specifying scale), indicating a 5‑fold slowdown; using double is recommended when high precision is unnecessary.

In summary, seemingly minor details—choosing the right sort method, avoiding calculations inside comparators, and preferring primitive arithmetic over BigDecimal —can reduce the endpoint’s execution time from 7‑8 seconds to 500‑600 ms, while larger gains would require a different algorithmic approach.