The Artima Developer Community
Sponsored Link

Java Community News
Heinz Kabutz on Optimizing Java Code

3 replies on 1 page. Most recent reply: Oct 11, 2007 8:48 AM by James Watson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 3 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Heinz Kabutz on Optimizing Java Code Posted: Oct 10, 2007 1:07 PM
Reply to this message Reply
Summary
In an interview with Sun Developer Network, Heinz Kabutz discusses why early optimization of Java code may prevent the compiler from creating the most efficient byte code.
Advertisement

Most developers understand that early optimization of code almost always produces the wrong outcomes. In a recent interview with Sun Developer Network, Heinz Kabutz, a Java Champion and author of the Java Specialist newsletter, illustrates this point in the context of String concatenation:

In the early days of Java programming, I sometimes resorted to "clever" coding. For example, when I was optimizing a system ... I changed the String addition to use StringBuffer after we had optimized the architecture and design of the system and wanted to improve things a bit...

String is immutable, so the compiled code will create many intermediate String objects, which can strain the garbage collector... A common remedy is to introduce StringBuffer...

StringBuffer result = new StringBuffer();
result.append(s1);
result.append(s2);
result.append(s3);
result.append(s4);
result.append(s5);
result.append(s6);
return result.toString();

Using JDK 6.0_02 and the server HotSpot compiler, I can execute [a version based on simple String concatenation] a million times in 2013 milliseconds, but [the StringBuffer-based version] in 734 milliseconds. At this point, I might congratulate myself for making the code three times faster. However, the user won't notice it if 0.1 percent of the program becomes three times faster...

Sun introduced the StringBuilder class in J2SE 5.0, which is almost the same as StringBuffer, except it's not thread-safe. Thread safety is usually not necessary with StringBuffer, since it is seldom shared between threads. When Strings are added using the + operator, the compiler in J2SE 5.0 and Java SE 6 will automatically use StringBuilder. If StringBuffer is hard-coded, this optimization will not occur.

As Kabutz's example shows, the simple concatenation with the + operator allows the compiler to substitute those operations with the use of StringBuilder.

What do you think of Kabutz's examples of early optimization problems?


Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Heinz Kabutz on Optimizing Java Code Posted: Oct 10, 2007 10:54 PM
Reply to this message Reply
Heinz appears to have demonstrated that the StringBuffer is three times faster than the StringBuilder but is no more complex. Yet the conclusion is to go with the StringBuilder so that the compiler can do some internal optimization.

Knowing the dangers of 'premature optimization' and given that, in this case, neither solution is more complex; I'm not sure I agree with the conclusion that the slow method is better.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Heinz Kabutz on Optimizing Java Code Posted: Oct 11, 2007 8:46 AM
Reply to this message Reply
> Heinz appears to have demonstrated that the StringBuffer
> is three times faster than the StringBuilder but is no
> more complex. Yet the conclusion is to go with the
> StringBuilder so that the compiler can do some internal
> optimization.

I think you misunderstood the conclusion which is not your fault given that there is no link (that I can see) to the original interview.

This is not exactly news as it's a well known issue even before StringBuilder was introduced. I wrote an entry in the Java wiki about this exact issue years ago:

http://wiki.java.net/bin/view/Javapedia/AlwaysUseStringBufferMisconception

> Knowing the dangers of 'premature optimization' and given
> that, in this case, neither solution is more complex; I'm
> not sure I agree with the conclusion that the slow method
> is better.

The StringBuilder should be faster than the StringBuffer. My guess is that in order to force 'slow' concatentation he used something like this:
String result = s1;
result += s2;
result += s3;
result += s4;
result += s5;
result += s6;

Which is probably converted to something like:
String result = s1;
result = new StringBuilder(result).append(s2).toString();
result = new StringBuilder(result).append(s3).toString();
result = new StringBuilder(result).append(s4).toString();
result = new StringBuilder(result).append(s5).toString();
result = new StringBuilder(result).append(s6).toString();

But if you do this:
result = s1 + s2 + s3 + s4 + s5 + s6;

It gets converted into something like:
result = new StringBuilder().append(s1).append(s2).append(s3).append(s4).append(s5).append(s6).toString();


In short, if you have to do multiple +=, you are still going to want to use StringBuffer or StringBuilder explicitly.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Heinz Kabutz on Optimizing Java Code Posted: Oct 11, 2007 8:48 AM
Reply to this message Reply
http://java.sun.com/developer/technicalArticles/Interviews/community/kabutz_qa.html

Flat View: This topic has 3 replies on 1 page
Topic: Bill Burke Comments on JAX-RS (JSR 311) Previous Topic   Next Topic Topic: Sun Releases Consumer JRE for Windows

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use