With the help of my friend we did a small test to understand the behavior of StringBuilder and String in terms
- Execution Time
- Memory
We executed the following piece of code
class Program
{
ulong SessionID = 1000;
ulong UserID = 292902;
String GLOBESNAME = “XXX”;
static void Main(string[] args)
{
Stopwatch sw = new Stopwatch();
sw.Start();
for (int i=0; i < 1000000; i++)
{
Program p = new Program();
p.getXML();
}
sw.Stop();
Console.WriteLine(sw.ElapsedMilliseconds.ToString());
Console.Read();
}
private void getXML()
{
String xml = @”<INPUTXML>
<SESSIONID>” + SessionID.ToString() + @”</SESSIONID>
<USERID>” + UserID.ToString() + @”</USERID>
<GLOBESNAME>” + GLOBESNAME + @”</GLOBESNAME>
<LANGUAGE>ENGLISH</LANGUAGE>
<SEARCH>
<LOOKINGFORME>VAULT</LOOKINGFORME>
<LOOKINGFORMETYPE>ENTITY</LOOKINGFORMETYPE>
<LOOKINGFORMEREQUIRED>FALSE</LOOKINGFORMEREQUIRED>
<LOOKINGFOR>
<ACCESSTONAME>READ</ACCESSTONAME>
</LOOKINGFOR>
</SEARCH>
</INPUTXML>”;
}
}
The getXML method was changed for StringBuilder.Append and StringBuilderAppenFormat.
StringBuilder.Append
===========================================================
StringBuilder sb = new StringBuilder(500);
sb.Append(@”<INPUTXML>
<SESSIONID>” + SessionID.ToString() + @”</SESSIONID>
<USERID>” + UserID.ToString() + @”</USERID>
<GLOBESNAME>” + GLOBESNAME + @”</GLOBESNAME>
<LANGUAGE>ENGLISH</LANGUAGE>
<SEARCH>
<LOOKINGFORME>VAULT</LOOKINGFORME>
<LOOKINGFORMETYPE>ENTITY</LOOKINGFORMETYPE>
<LOOKINGFORMEREQUIRED>FALSE</LOOKINGFORMEREQUIRED>
<LOOKINGFOR>
<ACCESSTONAME>READ</ACCESSTONAME>
</LOOKINGFOR>
</SEARCH>
</INPUTXML>”);
For StringBuilder.AppendFormat
===========================================================
StringBuilder sb = new StringBuilder(500);
sb.AppendFormat(@”<INPUTXML>
<SESSIONID>{0}</SESSIONID>
<USERID>{1}</USERID>
<GLOBESNAME>{2}</GLOBESNAME>
<LANGUAGE>ENGLISH</LANGUAGE>
<SEARCH>
<LOOKINGFORME>VAULT</LOOKINGFORME>
<LOOKINGFORMETYPE>ENTITY</LOOKINGFORMETYPE>
<LOOKINGFORMEREQUIRED>FALSE</LOOKINGFORMEREQUIRED>
<LOOKINGFOR>
<ACCESSTONAME>READ</ACCESSTONAME>
</LOOKINGFOR>
</SEARCH>
</INPUTXML>”,SessionID,UserID,GLOBESNAME);
The reading for execution time was done through Stopwatch class and the reading for memory was taken using ANTS Profiler.
The idea was execute the getXML method 10,000,000 times and determine which out of three methodology is best for string concatenation. The three method considered was
a. String
b. StringBuilder.Append
c. StringBuilder.AppendFormat
For StringBuilder we considered two cases
a. With inital capacity
b. With Capacity
the above was done only for execution time, we ignore this for Memory load.
The results were SHOCKING compare to our belief. We are still not sure that we are right and would like comment from Microsoft CLR team about the behaviour.
The results for execution time is
The 500 in the above stats means that StringBuilder initial capacity was set to 500.
The readings for memory load taken using ANTS profiler is as follows
The columns are
a. Number of Objects Created.
b. Total Size for entire allocation.
c. Number of time the Garbage Collector was called.
The results are really SHOCKING. It seems concatination using String object is THE MOST EFFICIENT methodology. This is contradictary to what the internet have been saying since the inception of .NET.
ITS A REQUEST TO ALL, TO RUN THE ABOVE CODE AND SHARE YOUR RESULTS. WE ALSO REQUEST THE .NET CLR TEAM TO COMMENT ON THIS.
Filed under: .NET Framework, ASP.NET, C# | Tagged: .NET CLR, CLR, String, String Performance, StringBuilder | 2 Comments »