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?

Solution 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.

Solution 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();

Solution 3

For small concatenations you can simply use String and + for the sake of readability. Performance is not going to suffer. But if you are doing lots of concatenation operations go for StringBuffer.

Comments

[Navi]

Similar queation here stackoverflow.com/questions/4645020/…

[Greg Mattes]

possible duplicate of StringBuilder vs String concatenation in toString() in Java

[Joshua Goldberg]

Possible duplicate of StringBuilder vs String concatenation in toString() in Java

[avgvstvs]

The compiler turns two Strings "Subject " + " Predicate" into

[avgvstvs]

buf.append("Subject").append("Predicate").toString() ?

[Jon Skeet]

@matt.seil: Actually, if there are string constants involved, the Java compiler will just use "Subject Predicate". But yes, it uses StringBuffer/StringBuilder behind the scenes otherwise.

[avgvstvs]

Alright: so if constants are used, no calls are ever made, so technically, there's no performance hit at all? The compiler just concatenates A + B into AB as a single String object?

[Jon Skeet]

@matt.seil: Indeed - in that case using a StringBuffer would be a performance hit, creating more objects than required...

[avgvstvs]

In the Java Language spec, it SUGGESTS that this is what the compiler would do, leaving open the possibility that it would not. 15.18.1.2 Optimization of String Concatenation

[avgvstvs]

Any idea how long this optimization has been in effect in SUN JVM's and if it exists in IBM JVM's?

[gabuzo]

I think it is probably here in Sun's JVM since version 1.4 and I don't know if it exists on IBM's JVM. You can check with a decompiler such as jad to be sure.

[Michael]

A note: on Android with small strings compared to memory size (e.g. 1MB on a 512MB device), method2 runs with no problem, but method3 results in an OutOfMemory exception. Is this because of the second StringBuilder?

[Felix S]

Of course you only need the StringBuffer in a multithreaded environment. Use a StringBuilder if you don't need synchronization.