Re: The problems with StringBuilders...

[Andrew Haley <aph at redhat dot com>]

David Daney writes:
 > We had an enlightening (for me anyhow) discussion on IRC about the 
 > problems with Sun's new StringBuilder class.
 > 
 > Summary:
 > 
 > StringBuilder is kind of useless.  Because it is unsynchronized, the 
 > results of StringBuilder.toString() cannot share the underlying char 
 > array (a copy of the array must be made).  This is because there are 
 > race conditions that would result in a String changing its value after 
 > it is created if a copy were not made.

I see how this could happen, yes.

 > Having to copy the contents probably has a much overhead as all the
 > synchronization required by the StringBuffer that it replaces (and
 > that can share the array).

I doubt it.  I'd like to see some profile measurements to prove it.
Besides, is there any reason not simply to synchronize
StringBuilder.toString() ?

 > TODO:
 > 
 > If the compiler could do some sort of escape analysis on the 
 > StringBuilder objects,

If the compiler could do escape analysis we'd have much better
performance, for sure.  However, inheritance makes this very hard to
do in most cases.  It's on my list.

In general, it's really important that when we do performance
improvements we concentrate on things that can be proved by
measurement really to help.  This is often surprising.

Andrew.