Quick Cheap Win with StringBuilder

Having performed a lot of code review, I realized something recently: many developers don’t seem to notice the existence of StringBuilder, despite its 2+ years of existence. If you don’t know about it, you should. In short, StringBuilder is an unsynchronized version of StringBuffer. That is, its instances are not safe for use by multiple threads. The upside is that it’ll be faster than StringBuffer in most implementations as well. Think of Vector vs. ArrayList.

Now let’s think about our most common use of StringBuffer. What is it? I bet it’s inside a method, as a local variable, to concatenate a bunch of strings, just like this:

public String buildHQLString() {
    StringBuffer sb = new StringBuffer();
    // append a lot more things here
    return sb.toString();

It is safe to replace StringBuffer with StringBuilder in this very common case, because every thread has its own stack, in which local variables reside. So, next time you’re typing “StringBuffer sb = “, it’s a good time to reflect whether “StringBuilder sb = ” is more appropriate.

(In fact, I can’t think of a good reason to use StringBuffer now. Have any of you ever come across a case where you just absolutely have to use StringBuffer instead of StringBuilder? If anyone can enlighten me with a good, legit, uncontrived usage of StringBuffer in the comments, I’ll be grateful.)

(UPDATE: After reading the comments, I did some searching and come across this bug report concerning StringBuilder.

In short it’s about the fact that J2SE converts String concatenation to StringBuilder.append() calls. But it always uses the default StringBuilder constructor, which has the initial capacity hardcoded to 16! So it results in a lot of extendCapacity() calls.

What does this mean for us? To me, it is telling me these 2 things:

  1. Concatenate Strings intelligently (obviously)
  2. Provide reasonable value to StringBuilder(int capacity), instead of using StringBuilder no-arg constructor–BUT spend too much time on this and you’re doing the root of all evil, premature optimization

RecycleCrazy pointed out in his blog entry (http://jroller.com/page/recyclecrazy?entry=are_we_prone_to_over) that there’s probably not much point spending time doing optimization before finding out which parts of the app need to be optimized, how badly they actually perform, etc.

I agree with all his points.

For the StringBuilder case, though, it’s just a 1-2 second extra decision time and I think every good developer should know this and just automatically type “StringBuilder sb = ” when it’s used as a local variable. That is, we know it’s safe, so why waste (no matter how little) resources when you can help it?)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s