String Performance

String interning

It is common to create many string objects that contain the same sequence

of char-acters. These objects unnecessarily take space in the heap; since

strings are immut-able, it is often better to reuse the existing strings.

( for more details See Chapter 7 of OReilly Java Performance )

String encoding

While Java strings are UTF-16 encoded, most of the rest of the world uses

a different encoding, so encoding of strings into different charsets is a

common operation. The encode() and decode() methods of the Charset

class are quite slow if they process only one or a few characters at a time;

make sure that they are set up to process full buffers of data.

Network encoding

Java EE application servers often have special handling for encoding static

strings (from JSP files and so on);

( for more details see Chapter 10 of OReilly Java Performance. )

String concatenation is another area where there are potential performance

pitfalls.

Consider a simple string concatenation like this:

String answer = integerPart + "." + mantissa;

That code is actually quite performance; the syntactic sugar of the javac

compiler turns that statement into this code:

String answer = new StringBuilder(integerPart).append(".").

append(mantissa).toString();

Problems arise, though, if the string is constructed piecemeal:

String answer = integerPart;

answer += ".";

answer += mantissa;

That code translates into:

String answer = new StringBuilder(integerPart).toString();

answer = new StringBuilder(answer).append(".").toString();

answer = new StringBuilder(answer).append(mantissa).toString();

All those temporary StringBuilder and intermediate String objects are

inefficient. Never construct strings using concatenation unless it can be

done on a single (logical) line, and never use string concatenation inside a

loop unless the concatenated string is not used on the next loop iteration.

Otherwise, always explicitly use a StringBuilder object for better

performance.