Performance Comparison of various Java string connection modes

From: http://blog.csdn.net/bestseal/archive/2008/04/16/2296283.aspx

There are 19 writing methods for sword words and many writing methods for string connection in Java. For example, to connect 6 strings, the following five writing methods are acceptable. Which of the following statements is the simplest, which one is the most efficient.

Public static string concat1 (string S1, string S2, string S3, string S4, string S5, string s6 ){
String result = "";
Result + = S1;
Result + = S2;
Result + = S3;
Result + = S4;
Result + = S5;
Result + = S6;
Return result;
}

Public static string concat2 (string S1, string S2, string S3, string S4, string S5, string s6 ){
Stringbuffer result = new stringbuffer ();
Result. append (S1 );
Result. append (S2 );
Result. append (S3 );
Result. append (S4 );
Result. append (S5 );
Result. append (s6 );
Return result. tostring ();
}

Public static string concat3 (string S1, string S2, string S3, string S4, string S5, string s6 ){
Return new stringbuffer (s1.length () + s2.length () + s3.length () + s4.length () + s5.length () + s6.length ())
. Append (S1). append (S2). append (S3). append (S4). append (S5). append (s6). tostring ();
}

Public static string concat4 (string S1, string S2, string S3, string S4, string S5, string s6 ){
Return S1 + S2 + S3 + S4 + S5 + S6;
}

Public static string concat5 (string S1, string S2, string S3, string S4, string S5, string s6 ){
Return new stringbuilder (s1.length () + s2.length () + s3.length () + s4.length () + s5.length () + s6.length ())
. Append (S1). append (S2). append (S3). append (S4). append (S5). append (s6). tostring ();
}

The first method is the most practical and cumbersome method. In fact, I will have a headache when I see such code. All the friends who have read cutting-tive Java know how to use stringbuffer. There should be a lot of people using the second method. Of course, the 4th types of writing methods are the simplest and most beautiful, that is, they don't know what the performance is like. Java 5 adds a stringbuilder class, which is the same as the stringbuffer function, that is, there is no synchronization. Replacing stringbuffer with stringbuilder is certainly good for performance. In this way, 5th writing methods are generated.

It is convincing to do a test. I tested JDK 5 and JDK 6 on the same machine. Each function is executed 10000000 times (each input parameter is "A"). The following statements are used in milliseconds:

----------------------------------
I add JDK 3:
[Concat1] Time: <19656>
[Concat2] Time: <4032>
[Concat3] Time: <5671>
[Concat4] Time: <4469>

I added JDK 4:
[Concat1] Time: <36265>
[Concat2] Time: <12156>
[Concat3] Time: <13860>
[Concat4] Time: <12859>
-----------------------------------

JDK 5:
Concat1: 13776
Concat2: 5081
Concat3: 4944
Concat4: 4202
Concat5: 4047

JDK 6:
Concat1: 11801
Concat2: 3930
Concat3: 3976
Concat4: 3353
Concat5: 3440

It can be seen that the 1st writing methods are indeed the slowest, and the second writing method is much faster due to the use of stringbuffer. The strange thing is that 4th writing methods are actually very fast and faster than stringbuffer. What's wrong? In fact, if you have debugged the execution process of the string connection, you will know that Java will automatically use the stringbuilder. append () function to connect to the string when you use the 4th writing method. Therefore, the simplest 4th writing methods are fast enough. In JDK 5, the 5th statements are the fastest, because the total length is calculated in advance when the stringbuilder is created, eliminating the memory redistribution. However, there is no need to write this. JDK 6 has already optimized the 4th writing methods, but the 5th writing methods are slow.

It can be seen that the simplest 4th writing methods are more likely to be optimized for Java implementation. Just like SQL, the optimizer has room for optimization because of declarative writing. I think of two sentences:
1. Simple is beautiful. Everyone wants to see concise and bright code, rather than tedious code.
2. Performance optimization is the source of all evil