For a x value of 1000 (1000 function calls, with each function call looping 1000 times) I came up with the conclusion that the + operator (actually, I used “&” in vb.net) was faster than the StringBuilder method. This was with the both functions concatenation all on the same line. When I moved the concatenation to separate lines StringBuilder came out on top. Not by much mind you.

I concatenated the string “Test: ” followed by the loop counter variable (integer) nine times, calling the ToString method on it.

These are the averages I got:
Concat with ‘&’ - Same Line: 3.703125ms
Concat with ‘&’ - Separate Line: 4.28125ms
Stringbuilder - Same Line: 4
Stringbuilder - Separate Line: 4.078125

If you don’t have the for loop, results from one test to the next are likely to vary significantly. That is if your timer is even accurate enough to measure the few microseconds it would take to concatenate those strings.

In code, you don’t instantiate a million new StringBuilders. StringBuilders are a little expensive up front and the fact that you’re instantiating it inside the loop is where the time is lost.

Instantiation is expensive. That’s why the stringbuilder is so much better than traditional “+” concatenation that spans multiple calls.

In a coding project, you only create the StringBuilder once then you can use it to continually, efficiently concatenate your variable string, as needed. Please try pulling that line (”StringBuilder sb = new StringBuilder();”) out and check out the results… something like this:

protected void Page_Load(object sender, EventArgs e)
{
int iLoopTo = 30000;

DateTime dt = DateTime.Now;
string string1 = “”;
for(int i = 0;i <= iLoopTo;i++)
{
string1 = string.Concat(string1, i.ToString());
}
TimeSpan loopTS = DateTime.Now.Subtract(dt);
lblTimestamps.Text += loopTS.TotalMilliseconds + ” milliseconds for string.Concat”;

dt = DateTime.Now;
StringBuilder sb = new StringBuilder();
for(int i = 0;i <= iLoopTo;i++)
{
sb.Append(i.ToString());
}
loopTS = DateTime.Now.Subtract(dt);
lblTimestamps.Text += loopTS.TotalMilliseconds + ” milliseconds for StringBuilder”;

dt = DateTime.Now;
string string2 = “”;
for(int i = 0;i <= iLoopTo;i++)
{
string2 = string2 + i.ToString();
}
loopTS = DateTime.Now.Subtract(dt);
lblTimestamps.Text += loopTS.TotalMilliseconds + ” milliseconds for string = string +”;
}

My results show a pretty impressive performance difference:

13811.8812 milliseconds for string.Concat
31.2486 milliseconds for StringBuilder
23561.4444 milliseconds for string = string +

Thanks

Tests you did are really good and very detail. They proof that nothing is so obvious and simple. It is nice to see that there is another person in this world who thinks about same kind of crazy things

I would like to leave for developers the choice they will make whether to use different techniques based on number of concatenations + length of strings or just to use StringBuilder(capacity) everywhere.

I’ll have to disagree. The tests I did in this article precisely showed that under some circumstances, + concatenation is faster than StringBuilder, even when pre-allocated with the final capacity. Look at the first test where the concatenated string size is 10. + concatenations is faster up to 3 concatenations.

I understand that the more memory you allocate, the more work you create for the garbage collector. However, the work that is done by the garbage collector is also taken into account in my tests, as I simply measured the total elapsed time. Whatever work that is done by the GC is reflected in that total elapsed time.

Re the “for” loop, its purpose is to purely multiply the concatenation multiple times to get a more accurate measurement. It’s a typical practice in micro-benchmarks. The operation being measured is inside the loop.

So as you can guess we are creating additional work for a Garbage Collector and using more memory than it actually could be used.

In case of StringBuilder with specified capacity there will be only 1 object created in memory and *NO* additional work for Garbage Collector.

“+” operator takes more CPU time, Memory size and creates extra time for a Garbage Collector to clear the mess it built. Unlike StringBuilder with specified parameter saves memory space and CPU time as object will be allocated only ones and GarbageCollector won’t have anything to clean up after.

My Conclusion is: Use StringBuilder with specified capacity almost always.

http://blog.dotnetstyling.com/archive/2007/10/27/How-fast-SringBuilder-is.aspx