Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

StringBuilder/StringBuffer vs. "+" Operator

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?

like image 705
avgvstvs Avatar asked Jan 10 '11 15:01

avgvstvs


People also ask

Should I use StringBuilder or StringBuffer?

StringBuffer was introduced in Java 1.0 whereas StringBuilder class was introduced in Java 1.5 after looking at shortcomings of StringBuffer. If you are in a single-threaded environment or don't care about thread safety, you should use StringBuilder. Otherwise, use StringBuffer for thread-safe operations.

How do you decide whether to use a StringBuilder object or a StringBuffer object to store a String value?

If the Object value can change and will only be accessed from a single thread, use a StringBuilder because StringBuilder is unsynchronized. In case the Object value can change, and will be modified by multiple threads, use a StringBuffer because StringBuffer is synchronized.

Which of the following is more efficient StringBuilder?

The + operator will always be more efficient when the entire operation consists of concatenating exactly two strings.

Why do we use StringBuffer and StringBuilder in Java?

The StringBuffer and StringBuilder classes are used when there is a necessity to make a lot of modifications to Strings of characters. Unlike Strings, objects of type StringBuffer and String builder can be modified over and over again without leaving behind a lot of new unused objects.


2 Answers

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.

like image 166
gabuzo Avatar answered Oct 17 '22 05:10

gabuzo


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();
like image 24
Jon Skeet Avatar answered Oct 17 '22 03:10

Jon Skeet