this is great, so practical!!!
any other resources like this?
Java is fast, code might not be
61–70 of 259 posts
Re: Java is fast, code might not be
#62> Exceptions for Control Flow This one is so prevalent that JVM has an optimization where it gives up on filling stack for exception, if it was thrown over and over in exact same place.
Author here. Great callout. That's the -XX:+OmitStackTraceInFastThrow optimization, been around since JDK 5. The C2 compiler detects exceptions thrown repeatedly from the same site and starts reusing a preallocated instance without filling the stack trace. Good for performance, but it makes debugging harder in production since you lose the trace. You can disable it with -XX:-OmitStackTraceInFastThrow if you need the traces back.
Re: Java is fast, code might not be
#63For fillInStackTrace, another trick is to define your own Exception subclass and override the method to be empty. I learned this trick 15+ years ago.
It doesn't excuse the "use exceptions for control flow" anti-pattern, but it is a quick patch.
Re: Java is fast, code might not be
#64A subject close to my heart, I write a lot of heavily optimised code including a lot of hot data pipelines in Java. And aside from algorithms, it usually comes down to avoiding memory allocations. I have my go-to zero-alloc grpc and parquet and json and time libs etc and they make everything fast. It’s mostly how idiomatic Java uses objects for everything that makes it slow overall. But eventually after making a JVM…
> And aside from algorithms, it usually comes down to avoiding memory allocations.
I’ve heard about HFT people using Java for workloads where micro optimization is needed.
To be frank, I just never understood it. From what I’ve seen heard/you have to write the code in such a way that makes it look clumsy and incompatible with pretty much any third party dependencies out there.
And at that point, why are you even using Java? Surely you could use C, C++, or any variety of popular or unpopular languages that would be more fitting and ergonomic (sorry but as a language Java just feels inferior to C# even). The biggest swelling point of Java is the ecosystem, and you can’t even really use that.
Re: Java is fast, code might not be
#65Understanding algorithmic complexity (in particular, avoiding rework in loops), is useful in any language, and is sage advice. In practice though, for most enterprise web services, a lot of real world performance comes down to how efficiently you are calling external services (including the database). Just converting a loop of queries into bulk ones can help loads (and then tweaking the query to make good use of inde…
Author here. DB and external service calls are often the biggest wins, thanks for calling that out.
In my demo app, the CPU hotspots were entirely in application code, not I/O wait. And across a fleet, even "smaller" gains in CPU and heap compound into real cost and throughput differences. They're different problems, but your point is valid. Goal here is to get more folks thinking about other aspects of performance especially when the software is running at scale.
Re: Java is fast, code might not be
#66First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.
I really hate how completely clueless people on hn are about java. This is not, and has not been an issue for many many years in Java and even the most junior of developers know how to avoid it. But oh no, go and rust is alwaayssss the solution sure.
Can you provide any examples or evidence of Java apps that prove this?
Because in my experience as of 2026, Java programs are consistently among the most painful or unpleasant to interact with.
Re: Java is fast, code might not be
#67First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup. I wish Java had a proper compiler.
I worked on JVMs long ago (almost twenty years now). At that time most Java usage was for long-running servers. The runtime team staunchly refused to implement AOT caching for as long as possible. This was a huge missed opportunity for Java, as client startup time has always, always, always sucked. Only in the past 3-5 years does it seem like things have started to shift, in part due to the push for Graal native image.
I long ago concluded that Java was not a client or systems programming language because of the implementation priorities of the JVM maintainers. Note that I say priorities--they are extremely bright and capable engineers that focus on different use cases, and there isn't much money to be made from a client ecosystem.
Re: Java is fast, code might not be
#68JavaScript can be fast too, it's just the ecosystem and decisions devs make that slow it down. Same for Java, I have yet to in my entire career see enterprise Java be performant and not memory intensive. At the end of the day, if you care about performance at the app layer, you will use a language better suited to that.
"Enterprise Java" Factories! Factories everywhere!
Why do you think this plays out over and over again? What's the causal mechanisms of this strange attractor
Re: Java is fast, code might not be
#69I ran into 5 and 7 in a Flink app recently - was parsing a timestamp as a number first and then falling back to iso8601 string, which is what it was. The flamegraph showed 10% for the exception handling bit.
While fixing that, also found repeated creation of datetimeformatter.
Both were not in loops, but both were being done for every event, for 10s of 1000s of events every second.
Re: Java is fast, code might not be
#70When you're using a programming language that naturally steers you to write slow code you can't only blame the programmer.
I was listening to someone say they write fast code in Java by avoiding allocations with a PoolAllocator that would "cache" small objects with poolAllocator.alloc(), poolAllocator.release(). So just manual memory management with extra steps. At that point why not use a better language for the task?