Allows you to edit Strings in JDK 1.5+.
In prior JDK’s, use the slower StringBuffer.
StringBuilder.insert,
delete and replace are
fairly expensive operations since they have to shift the everything past that
point to make room or squeeze up. With replace, if
the replacement String is the same length as the one replaced, you don’t
have this problem.
To find out how many chars are in a StringBuilder
altready use length( );
To reuse a StringBuilder use setLength(
0 );
If you know the precise length of the String you are
building in advance, usually you can build it more efficiently with a char[]
ca and use new String(
ca ) to convert the result.
Estimating Initial Size
It is important to get a good initial estimate for the StringBuilder
size. If you guess too small, it will have to take time out to allocate a buffer
double the size, copy over the partially built String.
Further, you will have two char[] objects
cluttering the heap instead of just one. If you guess too large, you will nail
down space needlessly for the internal buffer. Here is some code to monitor your
estimates, allowing you to monitor them. Tweak the buffer sizes and permissible
limits until your program stops emitting error messsages when it runs. If you
don’t specify any size, the constructor will assume 16
bytes. Hint: sort the error messages and eliminate duplicates before examining
them.
I used this method to optimise the initial sizes of the StringBuilders
used in the static macros program that expands the macros used to generate the mindprod.com
website. It does a great many StringBuilder. appends,
though it also does a fair bit of I/O as well, since it has to read each file in
the website. Here are the results:
| Effect of StringBuilder Optimising |
|
Time Before Optimising |
Time After Optimising |
% improvement |
| Sun |
27.5 sec |
24 sec |
13% |
| Jet |
25 sec |
22.5 sec |
10% |
|---|
A cleverer version of this program would collect the actual range of values for
each StringBuilder and report them, along with a
report on which bounds are dangerously tight or overly loose. It might even give
you an idea of the distribution so you could deliberately allow rare cases to be
handled outside the range. You could implement this fairly simply by logging the
current StringBuffer size and the call point values
to a CSV or DataOutputStream file, then sorting it
and picking out the low and high values. You could also do it, albeit more
slowly, by looking up database records and maintaining the lowest and highest
length seen for each StringBuilder. You would not want this turned on in
production, but the simple bounds check in checkStringBuilderEstimate
has almost no overhead.
StringBuilder is the usual choice, preferably with an
high-side estimate of the final length.
StringBuffer is for old JDKs.
StringWriter is for when you have code that was
originally designed to write files.
You can use a ByteArrayStream as a sort of StringBuilder
for bytes.
Learning More
Sun’s Javadoc on
StringBuilder class : available:
Sun’s Javadoc on
String class : available: