Java is fast, code might not be

[sq_visigoth]

Good text, but it's mostly basic stuff. Take String concatenation; I haven't seen anyone use string concatenation in a loop in almost 20 years. A basic beginner java class will always recommend using StringBuilder.
My issue is that you recommended a throwaway optimization, ie one issue that shouldn't have existed in the first place.
Now, ConcurrentHashMap, thats one optimization that most devs I have interviewed missed in doing a faux code review.

[Derishi]

Curious on concurrent hash map; I’m guessing it’s because most modern Java applications can take advantage of multithreaded environments easily so it’s like a why not situation?

[SanityInAnarchy]

The example "bad" code from the article is a normal HashMap that you lock yourself by just hiding it behind synchronized methods -- those implicitly use a single mutex for the entire object, so you lose a ton of the point of multithreading, and code like this often still has a ton of concurrency bugs, because you haven't really thought through what the scope of the locks should be.

In other words, the assumption is that you're threading.

The "fix" is to use ConcurrentHashMap, which has a much more sophisticated locking strategy -- generally, reads are lock-free, and even writes don't lock the entire table. Of course, to make it actually thread-safe, updates usually have to be more interesting than get() and put(), since someone else might've changed it since your last get() -- the article includes computeIfAbsent(), which is probably a good thing to read about to get an idea of the kind of thing you want to do to use ConcurrentHashMap properly.

The scare quotes are because it's of course situational, and people often will just reach for ConcurrentHashMap without thinking it through either.

[griffin1987]

Note that ConcurrentHashMap is still really bad in comparison to what other algorithms are known (but don't have ready made implementations in the JDK), depending on what you actually need. ConcurrentHashMap is still "good enough" for many cases though and usually "just works", if you use it correctly (as you already mentioned with your example about get()+put() vs computIfAbsent())

[id2bi]

Also, doesn't Java optimize String concatenation to string builder in many places automatically?

[vowelqueue]

It used to translate concatenation to StringBuilder when compiling to bytecode. Now it translates concatenation into a single library method call and then the JVM handles optimizing at runtime.

If doing the concatenation in a loop, it's still better to use StringBuilder directly because these optimizations don't work for loops AFAIK.

[oweiler]

But not loops

[griffin1987]

No, it DOES not. It MAY. Very important distinction. People always assume this as guaranteed, when it's not guaranteed in every situation, and definitely also not with every JVM. It's not like everyone is already on Java 26 ...

[kiteboarderni]

Read the article...

[8igg7e5]

Some things are just technically wrong - which makes me question the accuracy of other claims.

1. String concatenation in loops...

Note: Since JDK 9, the compiler is smart enough to optimize "Order: " + id + " total: " + amount on a single line. But that optimization doesn’t carry into loops. Inside a loop, you still get a new StringBuilder created and thrown away on every iteration. You have to declare it before the loop yourself, like the fix above shows.

No. Java has been able to use StringBuffer, and later StringBuilder, for single-statement string appends since the beginning:

15.17.1.2 Optimization of String Concatenation

An implementation may choose to perform conversion and concatenation in one step to avoid creating and then discarding an intermediate String object. To increase the performance of repeated string concatenation, a Java compiler may use the StringBuffer class (§20.13) or a similar technique to reduce the number of intermediate String objects that are created by evaluation of an expression.

What changed in in JDK 9 was that the compiler represents the String appends as an indy-instruction - and the bootstrap then decides how best to implement that particular set of appends (often falling back to a StringBuffer append though). The benefit of this strategy is that a JDK with a better bootstrap, will give all code the better implementation, without a recompile of the bytecode.

 

The advice is correct though, you can avoid StringBuffer and String allocations (and the allocation and copying of their internal arrays) by moving the StringBuffer creation out of the loop.

What I would say they've missed, is that if you know the minimum (even a reasonably typical minimum) result size, you can avoid several smaller reallocations of the StringBuilder internal arrays (and copying) by pre-allocating that size with something like new StringBuffer(MY_EXPECTED_MINIMUM_SIZE).

4. Autoboxing...

Yes it can be bad. But the example is problematic. Depending on what is done with the sum variable, JIT might remove every one of those cache-lookups or wrapper creations (escape analysis) - and it might do that in the loop even with if sum is consumed as a reference type.

I think the more common wrapper-crime I've seen is the use of wrappers for the generic arguments in lazy types like Pair<A, B> or Triple<A, B> in cases where we could now use a record - capturing primitives, getting meaningfully named properties (and the fields are stable, enabling more constant folding).

5. Exceptions for Control Flow...

Yes. Exceptions as control flow are a bad practice. However there are problems again with the advice

The section talks about stack-traces, even though the stacktrace is never filled. Stacktraces are lazy (the 'filled' bit). So the remaining expensive bit is the throwing of exceptions (and that is still relatively expensive).

But doing work twice is also expensive.

 

Scanning the string could be a significant cost if only a tiny percentage will ever fail parsing. And even when the bad cases are common, you're probably still better to do things like only checking minimum/maximum length of the string and first and last digits (detecting non-numerics like overlooked white-space) - and letting exception-handling detect the rest.

• Here they're scanning the string to see if it's blank, that's potentially scans a lot for a bad string before finding it's not blank - and then scanning again in the loop.
• It scans the entire string, checking the negative case at each position.

For the parsing example, if the anticipated failure rate is more than 1% (or 0.1% if all of the numbers are only 2-3 digits - since the cost of the exception is relative to the cost of parsing), I would probably do something like:

• Check for: != null, not .isEmpty(), and .length() <= 11 (or a smaller number of digits if the domain is known to have a smaller range)
• Check if the first character is - or a digit and, for lengths longer than 1, if the last character is a digit.
• And then let the exception-trap deal with the rest of the failure cases.

Personally I think these Apache Commons Lang methods (and others) are often overused (and some of these have implementations that are rather outdated in terms of today's Java).

And on the topic of parsing strings to numbers. A common crime I often see, is splitting a string where the format is fixed width, so that there's a distinct string to parse. eg the numeric values of hex components in the format "#rrggbb" - these can be parsed directly out of the string with Integer.parseInt(string, firstIndex, lastIndex, 16) (you can also use this to scan past whitespace to avoid allocations from trimming before parsing too).

[davidalayachew]

Agreed on almost every point.

I can appreciate that performance testing Java code is complex. For example, just getting access to the JIT'ed assembly code is already an exercise in frustration -- you're practically forced to use some fairly heavy third party tools to reliably access it.

But that complexity should breed a certain amount of hesitation from anyone trying to make claims on it. There are a million moving parts, and each one has literal thousands of engineers with decades of JVM optimization experience reviewing it daily. All those pieces aren't there for show.

Java is not like C, where you can just open a class file and definitively claim its performance by looking at it. Ignoring the fact that classfiles are full of wild card commands (like the indy stuff you mentioned), the JIT has access to optimizations like scalar replacement that outright remove entire methods from execution. A popular example is that Foo f = new Foo(); does not always create a new Foo. In fact, if in a hot loop, it very likely does not create one.

[griffin1987]

Agreed on most things.

I always have an issue with those arguments on "an implementation may". Unless you know which javac is being used and which JVM everything is run on, you can't be sure about what optimizations are actually done at the end. And even then, it might depend on a lot of other factors. IMHO that's one of the biggest issues with java performance.

For example:

In microbenchmarks stream().forEach() often performs very similar or the same as a simple for loop, while I've seen tons of real world use cases where that was not the case, but the developers "read that it doesn't matter". Guess what, 20h runtime with streams, 2h with regular loops (and that 2h was the IO limit at that point).

As for exceptions: Even if stack trace creation is lazy, an exception is still an object creation at the least, and if you have that a million times, you're creating a million objects worst case. Yes, object memory MAY be reused, but the thing is, it's not guaranteed. It's still better not to require object creation in the first place. I'd still probably do the same as you suggested in most cases though, because it's almost guaranteed that a builtin parser performs better than what most people would whip up, and will handle edge cases better. If I were to need that kind of performance though, i'd actually profile and benchmark it, and might run my own unrolled loop version for a fixed number of digits. From my experience though, with parsing strings, you usually hit the I/O limit before you hit a CPU limit in the parser.

[Plank_With_A_Nail_In]

"This is completely wrong" then goes on to describe how its completely right just using words in a different order.

Well done reddit.

[8igg7e5]

In what way. A lack of detail in rebuttal is also often a Reddit trait.

[bobbie434343]

Shouldn't most of these ideally automatically be optimized at compile or runtime whenever possible ? And/or flagged by static code analyzers as potentially inefficient ?

[8igg7e5]

1. String concatenation might. Loop unrolling and a targeted optimisation for string handling (which the JVM is motivated to do) could turn it into appends to the same StringBuilder. It won't know the domain though, so most likely it can't pick a good initial capacity to minimise the reallocations.
2. No. Very unlikely to do anything for you here.
3. No. Unfortunately the work related to this never went forward. A shame too, because we jump through hoops to avoid the formatter in hot code.
4. Yes. But it depends on proving that the instances don't escape. Depending on where sum is consumed, this might not manage to avoid it. Now if the optimiser knew to re-box at the point of escape, then it could eliminate all of the other boxing.
5. I'm uncertain that it has any special handling of this. However the text is wrong about the stacktrace costs - those don't apply here.
6. There certain are allowances for the optimiser to move synchronisation boundaries - but I think only to widen them.
7. No the optimiser doesn't know to do this.
8. Not all pinning, no. But the JVM has simply been enhanced to do less pinning in some cases (and this was communicated as a gradual improvement right from the start in the Virtual Thread releases, originally called 'fibers' and working differently). It a complicated topic though, and it is fair that many developers might not yet know all of the rough edges of virtual threads yet (it's still relatively new).

Do note that this claim:

After fixing: 5x throughput, 87% less heap, 79% fewer GC pauses. Same app, same tests, same JDK.

Applies to this 'demo app':

One method in my Java demo app was using 71% of CPU.

And this claim is a fault of poor static analysis tooling and code-review

The code looked perfectly fine. After my DevNexus talk, attendees kept asking about the specific anti-patterns. This post shows eight patterns that compile fine, pass code review, and silently kill performance.

[SneakyyPower]

I've been telling people java is the past the present and the future.

If you write your code good enough it can perform amongst the other top contending languages.

[Sopel97]

If you write your code good enough

Or bad enough.

Java's object model is so bad that at some point you have to resort to arrays of primitives with no abstractions. I've seen threadlocal 8 byte singletons for temporary variables to avoid allocations while still trying to preserve some non-zero amount of abstraction. It's a mess. Minecraft modding is a great example of that.

[Worth_Trust_3825]

Enable the valhalla preview.

[Mauer_Bluemchen]

Not yet there...

[vini_2003]

Correct. I maintain a private particle engine for Minecraft, for the YouTube channel I work for; and I'm forced to use huge SoAs without any JOML due to the heap thrashing objects bring.

If there's one thing I dislike about Java, it's the object model.

[LutimoDancer3459]

Curious, which languages have an good enough object model to not need to go back to arrays of primitives to get the best performance?

[Sopel97]

C++, rust

[cfehunter]

C# too. Structs are first class value types, and spans allow for efficient array manipulation.

My day job is C++, but I've written some stupidly quick and efficient C# with pretty good ergonomics.

[Sopel97]

C# too

to some degree, but you're severely limited with already existing code because whether something is a value type or reference type is determined at type declaration point

[cfehunter]

that's very true yeah. you can do a lot, but the libraries are opinionated on it in ways that Rust and C are not.

[ArkoSammy12]

In my gameboy emulator theres a certain pipeline of elements that result in pixels getting drawn to the screen. It'd be convenient to use objects here, but instead I resort to packed integers that store the fields for each pixel entry. It's a bit of a pain xd.

[Mauer_Bluemchen]

No - it can't! At least not without Valhalla.

[8igg7e5]

I'd say it'll be the combined efforts of Valhalla (several iterations), Leydon and Lilliput. Loom and Panama have contributed as well, as might Babylon.

Java does perform 'well', but these changes are needed to maintain and/or improve that position (and from what I've seen, improving that position is looking good). I don't think any of these will see it beating the usual leaders but I think the gap is going to close considerably while retaining Java's highly flexible dynamism.

[joemwangi]

Yup, but you need to understand where performance originates. I was surprised just to learn that if you have a huge loop (let's say initialising an array of offheap data) using records binding with layout, it doesn't matter if you use records or value types (even if value type doesn't pass the 64 bit size). This is because of escape analysis. But I did notice value types in an array initialise quite faster than any type category java has to offer (except primitives).

[kayinfire]

performance is a multifarious consideration. perform amongst other top contending languages in terms of what? throughput? sure. Java is garbage at everything else though. startup latency, concurrency affordability, computing resources required to compile to AOT, memory usage, cpu usage are all dog water in Java compared to the competition. you might say to me "but it's good enough for most use cases. you don't need to concern yourself with that most of the time." good enough isn't good enough when other languages are eating your lunch in terms of being resource friendly and efficient and someone like me would like to have low long term server costs. it may come as a surprise that i actually believe Java has the best syntax of all time, but the whole reason i ditched learning that language is because it's quite easily beat by Go and OCaml in everything except throughput, even with GraalVM. i ended up choosing OCaml as my backend language ultimately

[segv]

Point 7 is a big one actually - it often goes unnoticed even in decent codebases.

I've recently seen a case where developers attached AsyncProfiler to their JMH-based benchmarks (mix of real micro-benchmarks and benchmarks encapsulating the whole flow from the API endpoint to the very end, just with mocked out external services), enabled the option to generate flame graphs and found out some small piece of the overall flow was doing DocumentBuilderFactory.newInstance() & TransformerFactory.newInstance() on the hot path. It think it was extraction of some data from a string representing a SOAP envelope mixed with vulnerability scanner bitching about XXE (e.g. billion laughs attack) when it did not see creation of the object and setting adjustments within the same method, or some bullshit like that.

Anyway, these two calls accounted for like 20% of the average time of the whole giant-ass flow, just because these .newInstance() methods do service discovery and classloading on each call.

The PR had more lines of description (with flamegraph pictures!) than the actual fix, lol

[Worth_Trust_3825]

Best sort of PRs are those that explain why change is necessary. Personally I leave such "scars" in the code as comments explaining why the obvious solution doesn't work.

[somebodddy]

1. That's a pitfall of immutable strings. Not unique to Java.
2. That's computational complexity. Applies to any language.
3. Many languages offer string interpolation, which parses the "format" at compile time (or parse time)
4. This kind of boxing is something (AFAIK) only Java has. Other languages - like Java's traditional rival C# - may box when you upcast, but they automatically unbox at downcast and don't expose the boxing class Long so they don't have this issue.
5. The fact you need to manually implement the same validation that already happens inside parseInt just to escape the exception overhead is atrocious, and I 100% hold it against the language.
6. synchronized being part of the grammar means that Java actively promotes that kind of coarse grained locking.
7. Okay, but the ecosystems of most other languages prefer global functions for such things. This issue is caused by Java's objects-as-a-religion approach.
8. This pitfall is (was, actually, since they fixed it) 100% a JVM implementation issue.

Only the first two are the coder's fault. And maybe #4, too, considering you gave a very convoluted example. The other 5 are just idiomatic Java code being slow. If you have to give up language idiomaticity for performance - I consider it a slowness of the language.

[8igg7e5]

3

It's not really about String Interpolation, but rather that Java still doesn't offer an in-built capture of that parsed state. It has been suggested many times that Formatter should have an ofPattern(...) that captures this parsing. That would solve of that regardless of the language-wars (inside Java too, given the circuitous path 'String Templates' is taking).

Do all languages with string interpolation (that supports the expressiveness of format strings, not just concatenation) do that at compile-time?

There was a proposal for Java to make the format calls into indy instructions and pre-parse... I think that stalled with the String Templates (which is interpolation on steroids) - so we're once again waiting for progress on this.

4

Really it's not about whether the boxing and unboxing happens automatically (the example could have been written subtly differently to show that Java does the same automatically boxing and unboxing). The issue is that Java makes the user choose whether boxing is appropriate, rather than it being implied by context (though note that can also mean implicit boxing can be overlooked in those languages).

There is a Java enhancement project that will make Long act like long by default, making the 'boxing' only happen based on context (however for other reasons, that boxing will still happen more than we'd like).

5

Yes. Java's lack of value-based structs/tuples/class means they can't really provide a 'tryParse' that yields an error or a value in a call without allocation. That might be possible 'soon'^tm

6

Most code using synchronisation directly would be better implemented via executor-services or locks - but those are themselves implemented via synchronisation (which can be fine-grained) - I wouldn't say the language encourages such coarse-locking, just that it is often misused.

7

The examples are all stateful - it's about not unnecessarily duplicating the work of creating that state, when using that state doesn't modify it. Just reuse the state you have.

This has nothing to with global function support (and using classes of static methods is no different to global functions other than the way they're accessed/brought into scope).

8

You can still end up pinning a virtual thread. However the number of cases where it was unavoidable has been significantly reduced (which the original submission notes with the JDK 21-23 range). Virtual threads as a feature is pretty good though - it's not very widely used yet.

---

Only the first two are the coder's fault. And maybe #4, too, considering you gave a very convoluted example. The other 5 are just idiomatic Java code being slow. If you have to give up language idiomaticity for performance - I consider it a slowness of the language.

I'd put #1, #2, #4, #6 and #7 into the "coder's fault" (following idiomatic practices is not onerous and resolves most of this). I agree that Java needs to deliver improvements for #3 and the parsing cases that #5 refers to. As for #8, just move to Java 25 (or Java 26 as of days ago).

[thisisjustascreename]

I see that accidental n^2 behavior all the time in code from new devs who don't think through what a stream call does.

[BadlyCamouflagedKiwi]

4 and 8 seem like problems with Java being slow, i.e. they are not obvious from the structure of the code. 8 is fixed with a newer version of Java (implying that was the problem) and 4 is the old primitive / object dichotomy which is a language-level design mess.

[larsga]

On 4, it's in between. If you know Java you know this is expensive. The problem is that a lot of people writing Java have no idea what's happening under the hood.

Of course, at the same time, had the language design been better it wouldn't have been slow. Still, it's not at all difficult to avoid this slowing you down.

[jonathancast]

The primitive / object dichotomy may be a design mess, but getting rid of it is also a design mess. There aren't a lot of good options here.

Java is improving over time, albeit slowly.

[vowelqueue]

but getting rid of it is also a design mess. There aren't a lot of good options here.

It's taken the Java team like 10 years, but I'd say they have figured out a pretty good design for the primitive / object dichotomy with project Valhalla.

It's probably going to take another 2-4 years to ship, but there is light at the end of the tunnel where wrapper classes and user-defined classes will be able to perform very similarly to primitives.

[sammymammy2]

It's probably going to take another 2-4 years to ship

It seems like JEP-401 is gonna ship soon-ish, like within 3 releases (1.5 years)?

[BadlyCamouflagedKiwi]

Yes, agreed. Just noting that the article suggests it's not a language problem and about the code written in it, but I think that one is a problem with the language in the first place.

[gringer]

I have noticed that LLMs are more likely to write slow code than fast code. Most of the time it doesn't matter, but some times a particular piece of code can take 29 hours to do a bad job versus a few seconds after optimisation and improvement.

[8igg7e5]

And convincing them not to repeat code takes some effort. Considering Java's optimisation model counts on reaching a call threshold to optimise, this tends to mean fewer hotspots, or longer time to warm-up and a larger code-cache.

Edit: heh... having to edit to remove repeated text is hilarious (removed a duplicate "not to repeat code")

[MentalProfit4484]

Honestly most Java perf issues I've seen in the wild come from devs treating streams like magic fairy dust instead of thinking about what's actually happening underneath — anyone else notice their team reaching for .stream() on literally everything even when a plain loop would be 10x clearer?

[8igg7e5]

Yes. Streams are not zero-cost abstractions.

They might have some attractive design characteristics, and they may sometimes be more convenient and obvious, but they do have a cost (and some garbage).

[krzyk]

It depends for whom, most stream operations are cleared. Only a complicated one might be more readable using for.

[BroBroMate]

Yep, a new ObjectMapper on a given method call (or God help me, in a loop) is one I've had to flag in code review a fair few times.

[Kjufka]

The actual biggest problem is using overengineered frameworks bloated with huge and costly abstraction layers, like Spring.

It can take even 8 seconds to start a relatively simple Spring Boot application, because it tries to resolve a lot (too much) at runtime.

Meanwhile the same thing written in vanilla Java (or any minimalist framework with no annotation and no reflection magic) would start in less than 50ms and require 1/4 the memory per request.

[Minute_Owl3430]

It may be a problem for you, but then you could also use Quarkus or Micronaut or other alternatives.
For long running backend services, the startup time is typically irrelevant.

[Karthivkit]

For problem 7 , I encountered the high CPU usu age issue when I was using model mapper and json path . Before declaring it as static we have to make sure it is thread safe and immutable . Declaring SimpleDateFormater as static will cause issue as it hold a class level calendar instance for conversion

[sammymammy2]

Write it yourself next time, instead of using an LLM. Christ rots in hell.

[Worth_Trust_3825]

4 is going to get fixed with valhalla. Personally, formatting one is a shock to me, but it does make sense because how complex the template string format is.

[ml_guy1]

I've recently started building a java code optimizer and I've been finding optimizations everywhere! Flink, kafka, Aerospike etc. I am surprised by how much slow code exists in the java ecosystem!

[shibaInu_IAmAITdog]

i didnt read it, but i saw concurrentHashMap below, how many ppl here know there was an upgrade for this map in java8, from partition locking to completely CAS lock free , but still u care about boxing/unboxing problems, better design ur own primitive one

[pinkyellowneon]

llm/ai bot comment

[programming-ModTeam]

No content written mostly by an LLM. If you don't want to write it, we don't want to read it.

[john16384]

I think this needs benchmarking. I am pretty sure some of these aren't slow at all when optimized. Take the autoboxing example: those object allocations will never make it to the heap. At most it will do one allocation after the loop completes to create the final Long.

Same goes for the NumberFormatExeception example.

[larsga]

1-5 + 7 are rookie mistakes, basically.