commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: [lang] FastStringBuffer?
Date Thu, 07 Aug 2003 21:49:49 GMT
FYI, Java 1.5 will include a fast string buffer.


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


-----Original Message-----
From: Brian S O'Neill [] 
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" <>
To: "Jakarta Commons Developers List" <>
Sent: Wednesday, August 06, 2003 08:30 P
Subject: [lang] FastStringBuffer?

> Maybe I'm missing something, or maybe this has been discussed before,
> Is there a replacement for StringBuffer someplace, perhaps a
> "FastStringBuffer" class?
> I only ask because StringBuffers are used everywhere, even internally by
> 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
> to access the same StringBuffer.  So, why not eliminate the synchronized
> method calls and increase performance?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message