Java Best Practices – String performance and Exact String Matching

Continuing our series of articles concerning proposed practices while working with the Java programming language, we are going to talk about String performance tuning. We will focus on how to handle String creation, String alteration and String matching operations efficiently. Furthermore we will provide our own implementations of the most commonly used algorithms for Exact String Matching. Many of these algorithms can achieve far more superior performance compared to the naive approach for exact String matching available with the Java Development Kit. This article concludes with a performance comparison between the aforementioned Exact String Matching algorithms.

All discussed topics are based on use cases derived from the development of mission critical, ultra high performance production systems for the telecommunication industry.

Prior reading each section of this article it is highly recommended that you consult the relevant Java API documentation for detailed information and code samples.

All tests are performed against a Sony Vaio with the following characteristics :

• System : openSUSE 11.1 (x86_64)
• Processor (CPU) : Intel(R) Core(TM)2 Duo CPU T6670 @ 2.20GHz
• Processor Speed : 1,200.00 MHz
• Total memory (RAM) : 2.8 GB
• Java : OpenJDK 1.6.0_0 64-Bit

The following test configuration is applied :

• Concurrent worker Threads : 1
• Test repeats per worker Thread : 1000
• Overall test runs : 100

String performance tuning

Many people do not have performance in mind when they utilize String objects. Nevertheless misuse of String classes can significantly degrade the performance of an application. The most important things you should keep in mind are :

1. String objects are immutable. Once we create a String object we cannot change it. Every operation that alters a String results in the creation of at least one new object instance. For example concatenating two strings using the concatenation operator (+) results in the creation of two new objects, a temporary StringBuffer object used for the actual concatenation and the new String instance pointing to the concatenated result (the StringBuffer “toString()” operation is utilized to instantiate the resulting String). On the other hand using the String “concat(String ..)” operation to perform String concatenation will provide much better performance results compared to the concatenation operator (+) approach. Behind the scenes the String “concat(String ..)” operation utilizes the native “System.arrayCopy” operation to prepare a character array with the contents of the two concatenated Strings. Finally a new String instance is created that points to the concatenated result
2. String references are pointers to the actual String object instances. Thus using the “==” operator to compare two String instances representing identical literal contents will return “false” in case the actual String objects are different. Furthermore using the String “equals(String ..)” or String “equalsIgnoreCase(String ..)” operations to compare two String instances provides valid results but performs a character to character comparison in case the two compared Strings are represented by different instances and their literal contents have the same length. As you can imagine the “equals(String ..)” and “equalsIgnoreCase(String ..)” operations are far more costly compared to the “==” operator which compares the strings at instance level. Nevertheless the aforementioned operations perform an instance equality check (this == obj) prior all literal content checks. In order to be able to benefit from the “this == obj” equality check when comparing String instances, you should define String values as literal strings and/or string–valued constant expressions. Doing so, your String instances will automatically be interned by the JVM. An alternate, but not favored, approach is the use of String “intern()” operation so as to intern a String manually. As clearly stated in the Java documentation for the “intern()” method,
   
   “A pool of strings, initially empty, is maintained privately by the class String.

   When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned.

   Otherwise, this String object is added to the pool and a reference to this String object is returned.

   It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.

   All literal strings and string-valued constant expressions are interned.”

Our proposed best practices when working with Sign up