C# StringBuilder Performance

You are deciding whether to use StringBuilder instead of string when appending string data. Determine the point at which StringBuilder becomes more efficient. Here we see benchmarks of StringBuilder and strings, and discuss the important considerations when choosing between the two, using the C# programming language.

Benchmark

Here we see the code styles that were benchmarked to produce the graph. This is an adjunct article to my other StringBuilder work. What was tested here were tight loops that append a single string each iteration. The number of strings that were appended was steadily increased to determine the slope of the graph.

StringBuilder default code [red line] [C#]

StringBuilder builder1 = new StringBuilder();
for (int i = 1; i < count1; i++)
{
    builder1.Append(s);
}
return builder1.ToString();

StringBuilder with capacity [purple line] [C#]

StringBuilder builder2 = new StringBuilder(count1 * maxLength);
for (int i = 1; i < count1; i++)
{
    builder2.Append(s);
}
return builder2.ToString();

String concat [blue line] [C#]

string st1 = string.Empty;
for (int i = 1; i < count1; i++)
{
    st1 += s;
}
return st1;

StringBuilder benchmark results. My test tried to defeat every compiler optimization by using different strings of the same lengths to append. The tests were repeated 20 times more for counts below 8 strings. You can see the graph at the top of this article.

My interpretation. The benchmark indicates that using the string reference type with Concat is faster for one to four strings inclusive. Using StringBuilder with an accurate capacity is faster than StringBuilder always.

Best practices

Here we look at what I think the best way to use StringBuilder is. Use StringBuilder always when you have a loop of a variable length. This will make your program usable in more scenarios than string Concat will.

An example of the guideline. For example, if you have a program that has three strings 99% of the time, but 30,000 strings 1% of the time, using StringBuilder will make the program usable in that 1%. As always, one of the most important parts of good programming is planning for errors and edge cases.

Warning for algorithmic inefficiencies. Obviously, if your program is lightning fast 99% of the time, but fails 1% of the time, your program is unacceptable for important work. Therefore, I think StringBuilder is preferable in most loops.

Problems

There are many problems to this test. The individual strings themselves were 20 characters long. This may not match many programs in the real world. I didn't benchmark cases where there are hundreds of thousands of strings. However, it is clear to me that the trend of the lines would continue. The capacity settings I used were always 100% accurate, which in real-world programs might be unlikely. However, I feel the findings here encourage using capacities.

Summary

We saw some factors that will influence when you want to use StringBuilder in your C# programs. StringBuilder is entirely an optimization, and it offers no logical improvements to string Concat other than its internal implementation. Sometimes, it is okay to use small loops of four or fewer iterations with simple string concatenations. However, in edge cases this can be disastrous. Plan for your edge cases with StringBuilder.