StringBuilder/StringBuffer vs. "+" Operator

Question

I'm reading "Better, Faster, Lighter Java" (by Bruce Tate and Justin Gehtland) and am familiar with the readability requirements in agile type teams, such as what Robert Martin discusses in his clean coding books. On the team I'm on now, I've been told explicitly not to use the + operator because it creates extra (and unnecessary) string objects during runtime.

But this article, Written back in '04 talks about how object allocation is about 10 machine instructions. (essentially free)

It also talks about how the GC also helps to reduce costs in this environment.

What is the actual performance tradeoffs between using +, StringBuilder or StringBuffer? (In my case it is StringBuffer only as we are limited to Java 1.4.2.)

StringBuffer to me results in ugly, less readable code, as a couple of examples in Tate's book demonstrates. And StringBuffer is thread-synchronized which seems to have its own costs that outweigh the "danger" in using the + operator.

Thoughts/Opinions?

Answer 1

Using String concatenation is translated into StringBuilder operations by the compiler.

To see how the compiler is doing I'll take a sample class, compile it and decompile it with jad to see what's the generated bytecode.

Original class:

public void method1() {
    System.out.println("The answer is: " + 42);
}

public void method2(int value) {
    System.out.println("The answer is: " + value);
}

public void method3(int value) {
    String a = "The answer is: " + value;
    System.out.println(a + " what is the question ?");
}

The decompiled class:

public void method1()
{
    System.out.println("The answer is: 42");
}

public void method2(int value)
{
    System.out.println((new StringBuilder("The answer is: ")).append(value).toString());
}

public void method3(int value)
{
    String a = (new StringBuilder("The answer is: ")).append(value).toString();
    System.out.println((new StringBuilder(String.valueOf(a))).append(" what is the question ?").toString());
}

• On method1 the compiler performed the operation at compile time.
• On method2 the String concatenation is equivalent to manually use StringBuilder.
• On method3 the String concatenation is definitely bad as the compiler is creating a second StringBuilder rather than reusing the previous one.

So my simple rule is that concatenations are good unless you need to concatenate the result again: for instance in loops or when you need to store an intermediate result.

Answer 2

Your team needs to learn about the reasons for avoiding repeated string concatenation.

There certainly are times when it makes sense to use StringBuffer - in particular when you're creating a string in a loop, especially if you aren't sure that there will be few iterations in the loop. Note that it's not just a matter of creating new objects - it's a matter of copying all the text data you've appended already. Also bear in mind that object allocation is only "essentially free" if you don't consider garbage collection. Yes, if there's enough room in the current generation, it's basically a matter of incrementing a pointer... but:

• That memory must have been cleared at some point. That's not free.
• You're shortening the time until the next GC is required. GC isn't free.
• If your object lives into the next generation, it may take longer to be cleaned up - again, not free.

All of these things are reasonably cheap in that it's "usually" not worth bending a design away from elegance to avoid creating objects... but you shouldn't regard them as free.

On the other hand, there is no point in using StringBuffer in cases where you won't need the intermediate strings. For example:

String x = a + b + c + d;

is at least as efficient as:

StringBuffer buffer = new StringBuffer();
buffer.append(a);
buffer.append(b);
buffer.append(c);
buffer.append(d);
String x = buffer.toString();