While running final tests, we noticed extremely erratic runtime behavior. This was difficult to reproduce, but very frustrating because it meant the application runtime increased from 5 to almost 14 minutes. This article describes how we diagnosed the issue and distilled it down to a few test cases. These might help us find some answers. Perhaps we’ve discovered a defect or at least a strange edge case in the JVM.

When our Java code processes certain data first, it compiles machine code that contains many uncommon trap markers, which seem to affect runtime behavior (this is just an observation, not a firm conclusion). When different data is processed later, the JIT compiler sticks with its initial compilation, and the runtime suffers by a factor of 2 to 5. If we change the order of the data, the runtime behavior improves dramatically, and even the data that previously led to the potentially poor code now runs fine.

We can change the code to mitigate the problem, but we are still interested in understanding why Java’s JIT compiler reaches its conclusions and persists with them. The code in question is compatible with almost any Java version and doesn’t use any advanced features.

Since I just read again the advice to always use StringBuilder instead of String concatenation, we will close this chapter once and for all, right now!

Long story short, using StringBuilder instead of String concatenation is just an old myth. In most cases, it is not true anymore. You can safely do a String1 + String2 in your code, and you won’t notice any difference. There are only a few special cases where a StringBuilder is a must.

Recently I saw some benchmarks^[1] about converting int to String and of course, I got curious. This post shows that the results are legit, but have to be taken with a grain of salt.

While the benchmarking started out quite normally, it turned into an investigation of accuracy and meaning. What goes into the result, does the difference make sense, and where does all that noise come from? How much should we care?

At the end, you have learned that time is relative, memory expensive, and a small difference not really worth the effort. Or in English: Don’t believe any random benchmark you just found on the Internet!

Recently, I read posts about some Java loop benchmarks. I am not entirely sure, if the outcome and advise given is correct, so here is my version. I don’t want to blame any of the other tests for being incorrect, but judge for yourself.

Spoiler alert: The type of loop might or might not make a difference and overall, it is rather not the loop that makes the difference but all the other code that leads to conditions that might make some loops run faster, despite the same work/task. And yes, parallelStream() is mostly a bad idea.

This article also will give you a brief glimpse into benchmarking as well as teach you, that most benchmarks are wrong or better, the benchmark is right but the conclusions are wrong. Bring some time, the article got longer than expected. The article is not going to teach you how to benchmark with JMH, how the JVM works, or how that all is executed by the CPU. It might just overwhelm you with facts. But hey, it is not supposed to be the last article on that subject.