Recently I have encountered a few articles on the web about performance in Java. The authors were comparing the execution time of different code snippets implementing the same functionality and tried to make conclusions about which one is more efficient. I have to say that I find the topic really interesting. I have seen a lot of different attempts of micro benchmarking Java performance – some more naive, some quite reasonable.

In one of less successful posts about micro benchmarking in Java on one of many blogs someone left a comment linking to two articles written by Brian Goetz that I would like to show you today. If you think that performance analysis in Java is hard, he will show you that it is even harder than you would imagine. To quote Brian:

“So, how do you write a perfect microbenchmark? First, write a good optimizing JIT. Meet the people who have written other good, optimizing JITs (they’re easy to find, because not too many good, optimizing JITs exist!). Have them over to dinner, and swap stories of performance tricks on how to run Java bytecode as fast as possible. Read the hundreds of papers on optimizing the execution of Java code, and write a few. You will then have the skills you need to write a good microbenchmark for something like the cost of synchronization, object pooling, or virtual method invocation.”

Those are the mentioned articles: First one deals with all the nasty and important details one has to consider to start benchmarking (compiler optimizations, JVM specifics, etc) and gives an example of how they can bite you in your behind. Second one is a real-life example of an attempt of performance analysis that at first glance appears reasonable. After a close look it turns out to have tons of problems and flaws that basically obscure the intended measurements. Both of those articles are fascinating – reading is a must!