2

I'm aware of the difference between concat, StringBuffer and StringBuilder. I'm aware of the memory issue with the StringBuffer.toString backing array which can explode memory. I'm even aware of the JDK Sun optimization consisting in allocation a power of two for initial capacity.

But I'm still wondering about the best way to reuse a StringBuffer (used in toString()) or, if reusing the StringBuffer is pertinent. Which one is better with memory and speed performance in mind ? 

public String toString2() {
  StringBuffer sb = new StringBuffer(<size>) 
  ... several .append(stuff) ...
  sb.trimToSize()
  return sb.toString()
}

or 

private StringBuffer sb = new StringBuffer(<size>) 
public String toString2() {
  sb.delete()
  sb.setLength(1024)
  sb.trimToSize() 
  ... several .append(stuff) ...
  return sb.toString()
}

And why ?

Zofren
  • 1,190
  • 2
  • 11
  • 22
  • Why in the world would the `toString()` method of *anything* be a performance bottleneck? If it is, then chances are that `String` is probably not the ideal thing to use for whatever operation you plan to do with it. – Joachim Sauer Apr 16 '12 at 09:09
  • This question might be related http://stackoverflow.com/questions/5192512/how-to-clear-empty-java-stringbuilder . Another consideration would be thread safety, in the second option two threads calling `toString´ concurrently would get the wrong result. – Jörn Horstmann Apr 16 '12 at 09:23
  • My application is very strongly real time and multithreaded. And the toString() method is really a bottleneck because we have a deep aggregated object to log for support. – Zofren Apr 16 '12 at 09:39
  • @Zofren: then maybe logging that information in a more compact, easier-to-produce, binary format might be worthwhile. – Joachim Sauer Apr 18 '12 at 12:50

4 Answers4

3

I would say the first example is definitely clearer, easier to read and safer - which should almost always trump performance micro-optimization concerns. If you do have a performance problem, and you can prove (with concrete measurements) that it is caused by this piece of code, and you can also prove by measurement that in your local environment, the 2nd example is significantly faster, then - and only then - you have a valid reason to use that.

Otherwise, there is no general answer to your question. What would it help you if people claimed that the 2nd example were faster by n% on average, if it doesn't make any difference on your machine (either because of a different environment, or because the actual piece of code is called so rarely in your app)?

However, my personal gut feeling is that on a modern JVM (read: at least on JDK6, but possibly already on JDK5), the first example might actually be faster, due to clever GC tricks making allocation / deallocation of short-lived objects extremely cheap. Especially so if you used a StringBuilder instead of StringBuffer, which has no synchronization overhead.

Péter Török
  • 114,404
  • 31
  • 268
  • 329
  • 1
    Note also that the second example is not thread safe at all: you can get mangled `toString()` values if you execute it in multiple threads at once. – Joachim Sauer Apr 16 '12 at 09:08
2
  1. Use StringBuilder, a non-synchronized variant of StringBuffer -- that gives you a performance boost straight out of the box.
  2. No need to call trimToSize -- you are just forcing the StringBuilder to make a new char array.
  3. You'll save very, very little by reusing a StringBuilder since the JVM is highly optimized for the allocation of short-lived objects.
  4. Use StringBuilder instead of a simple concatenation expression only if you cannot express your string in a single expression -- for example, you are iterating over some stuff. Concatenation compiles to basically the same code using the StringBuilder.
Marko Topolnik
  • 195,646
  • 29
  • 319
  • 436
  • I'm in an heavy iterating recursive log, that's why I asked. Your point 3 is what I wanted to be assured of. – Zofren Apr 16 '12 at 09:41
  • `StringBuffer` may be a short-lived object but it has an internal buffer which may get resized frequently. Shouldn't the builder be reused in this case, to avoid buffer reallocation (ie. with a call to `#setLength(0)`)? – rath Feb 25 '16 at 10:28
  • 1
    @rath That's true, but it very often does not matter. Giving a good initial size reduces the likelihood of resizing. Also keep in mind that reusing the same string builder makes the method not thread-safe. A notorious example of adverse consequences of such design is the `DateFormat` class. – Marko Topolnik Feb 25 '16 at 19:42
0

I wouldn't use StringBuffer at all esp if performance is a concern.

If you can't be sure that only one thread will call toString(), I would create a StringBuilder each time.

The other problem you have is that different data types can create a lot of garbage e.g. int or double and this can reduce any benefit you might achieve.

I wouldn't recycle StringBuilder, I would just keep things simple. If you really need the maximum performance I would use a different solution like a direct ByteBuffer with a library which creates no garbage.

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
0

Try performance testing both. As with all questions of performance it'll depend on the context and how the methods are called.

A couple of notes:

  • StringBuilder is not thread-safe, but in your 1st example thread-safety is not an issue as your method is not using an fields. This makes StringBuilder faster than StringBuffer.
  • Your second approach is not thread-safe, so if you have multiple threads calling the method, then both threads will use the safe StringBuffer, so you'll end up with a string that contains elements from both calls.
  • If you keeping the StringBuffer around (2nd example), depending on how often you use the method, you may actually be holding on to more memory because the garbage collector will not collect the memory used by the StringBuffer, which could be used by other objects.
beny23
  • 34,390
  • 5
  • 82
  • 85