FYI, Java 1.5 will include a fast string buffer. From http://developer.java.sun.com/developer/community/chat/JavaLive/2003/jl0729. html:
"Laurence Vanhels: From profiling sessions, it's clear that any Java program produces a huge number of String objects. Does the new release include any new clever optimizations to speed up the general use of Strings? Neal Gafter: Yes! String concatenation is fairly slow right now because StringBuffer is fully synchronized. We're adding an unsynchronized version, java.lang.StringBuilder, with the same functionality but not synchronized. It will be used by the compiler to compile string concatenation expressions, and this should significantly improve performance for some applications." Gary -----Original Message----- From: Brian S O'Neill [mailto:[EMAIL PROTECTED] Sent: Thursday, August 07, 2003 07:02 To: Jakarta Commons Developers List Subject: Re: [lang] FastStringBuffer? The big advantage that the StringBuffer has is that it's defined in the java.lang package. As a result, it has access to package private members of the String class. Calling toString on StringBuffer does not allocate a copy of the characters, but rather passes the reference to it's char[]. With any FastStringBuffer class, a copy will be created. This will likely hurt performance much more than removing synchronization. ----- Original Message ----- From: "Chris Feldhacker" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, August 06, 2003 08:30 P Subject: [lang] FastStringBuffer? > Maybe I'm missing something, or maybe this has been discussed before, but... > > Is there a replacement for StringBuffer someplace, perhaps a > "FastStringBuffer" class? > > I only ask because StringBuffers are used everywhere, even internally by the > JVM. However, all of the methods on the StringBuffer class are > synchronized. In my experience (and in looking through most of the lang > code), 99% of the time StringBuffer is only used as a method variable to > compose a message String; therefore, it is not possible for multiple threads > to access the same StringBuffer. So, why not eliminate the synchronized > method calls and increase performance? > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]