March 20, 2026
Benchmarks and brawls
Java Is Fast. Your Code Might Not Be
Dev speeds Java 5x; comments erupt: “Use Rust” vs “Write better code”
TLDR: A dev sped a Java app 5x by removing common slowdowns, proving “Java is fast, your code isn’t.” Comments split between “switch to Rust/Go,” complaints about Java’s slow warm-up, and pragmatists saying the real gains come from better queries—showing performance is part code, part culture.
A Java dev claims a glow-up: the same app went from 1,198ms to 239ms and from 85k to 419k orders per second by fixing everyday bad habits—like gluing strings together the slow way, re-counting lists in loops, and throwing exceptions as if they were if-statements. No new servers. No new Java version. Just cleaner code.
But the comments? Pure fireworks. One camp screams, “Just use Rust”—with koakuma-chan saying everybody should switch and roasting Java’s build tools. Another camp insists the problem isn’t Java, it’s sloppy code and rework. bearjaws throws gas on the fire with, “I have yet to… see enterprise Java be performant,” while others argue the real bottleneck is usually the database or other services—batch the queries, save the day, says liampulles.
Then kyrra drops the cold truth about Java’s warm-up time: early requests crawl until the just-in-time (JIT) compiler finishes optimizing hot paths, wishing Java had a "proper compiler" like C++/Go/Rust. Meanwhile, tripple6 delivers zen wisdom—“Do good, don’t do bad”—which the thread instantly turns into a meme.
The vibe: Java is fast, but your code (and choices) might not be. Some want new languages, others want better habits. The only thing everyone agrees on? Profiling and fixing real-world anti-patterns is cheaper than a fleet upgrade—and way less embarrassing in a code review.
Key Points
- •Performance optimization of a Java order-processing app reduced elapsed time from 1,198ms to 239ms and increased throughput from 85k to 419k orders/sec.
- •Peak heap usage fell from just over 1GB to 139MB and GC pauses dropped from 19 to 4 without changing architecture or JDK.
- •Eight anti-patterns are identified, including string concatenation in loops, O(n²) streams in loops, String.format in hot paths, autoboxing, exceptions for control flow, broad synchronization, recreating heavy objects, and virtual thread pinning.
- •String concatenation in loops leads to O(n²) copying due to immutability; the fix is a single StringBuilder declared before the loop. JDK 9 optimizes single-line concatenations but not loop cases.
- •Virtual threads in JDK 21–23 can be pinned by synchronized sections combined with blocking I/O, impacting performance.