your articles on this topic are really good, especially the one on InfoQ. I wanted to write an article on Escape Analysis and you’ve done such a nice job that I’ll leave my readers to catch up on a great definition from your article.

However, I’ve discovered something rather interesting to do with Escape Analysis that I think I’ll publish before the end of 2009

Regards from Crete, come visit us here some time

Heinz

You made a good point about premature optimizations. It triggered me to investigate and write this blog, because your StringBuilder vs. StringBuffer measurements mismatched with my assumption that Escape Analysis was working. It evolved in my further articles on InfoQ (with help of Kirk):
http://www.infoq.com/articles/java-threading-optimizations-p1

Jeroen.

only saw your reference to my interview now. My point was not to show that StringBuilder was faster than StringBuilder, but rather that premature optimizations lets us do unnecessary work that may result in slower code.

You could have just as well written your method

public static String concatBuilder(String s1, String s2, String s3) {
return s1 + s2 + s3;
}

which could take advantage of future improvements of the String concatenation.

In your example, your Strings are very short, so there is no expansion of the underlying array. Under other circumstances it would be faster to first size the array and then create the StringBuilder. You could even reuse the StringBuilder, which again, can improve the performance. These changes could be added into your code by the javac compiler, as long as you stuck the simple and clean s1 + s2 + s3.

Hope that clarifies my point a bit better now? Don’t optimize prematurely!

Heinz

StringBuffer: 2764 ms.
StringBuilder: 2395 ms.
Thread safety overhead of StringBuffer: 15%

java -version
java version “1.6.0_14″
Java(TM) SE Runtime Environment (build 1.6.0_14-b08)
Java HotSpot(TM) Server VM (build 14.0-b16, mixed mode)

It’s actually a mistake to use -XX:CompileThreshold=1 as it will cause worse code to be generated. The reason for this is that the JIT has not collected enough profiling information. In general, it’s best not to change that setting and to simply allow enough time for the JVM to warm up.

Ismael

http://www.infoq.com/articles/java-threading-optimizations-p1

Cheers, Jeroen.

java version “1.6.0_06″
Java(TM) SE Runtime Environment (build 1.6.0_06-b02)
Java HotSpot(TM) Server VM (build 10.0-b22, mixed mode)