I was originally going to title this article "Stop using StringBuilder." However, once I actually started doing these performance tests, I decided it's not so easy to say that StringBuilder is rarely warranted. I've always read that C# string concatenation is very efficient, and StringBuilder is generally not necessary for small tasks. So when I found myself in a code review session having to approve a change that only replaced 15ish string concatenations with a StringBuilder, I was annoyed. But, I didn't have solid evidence that this was unnecessary so I set out to prove that StringBuilder is pointless at the scale I was looking at. And I was probably right, but it turns out it's not as simple as that.

Benchmarking

First things, first: how did I perform these benchmarks? The bulk of the answer is by using BenchmarkDotNet which is purpose built for exactly what I'm trying to do. I enabled memory diagnostics so that I could compare memory usage of the methods in addition to simple execution time. Otherwise, I used the default configuration. I ran the benchmark in DotNetCore 2.1 on my laptop (a Lenovo Thinkpad X1 Carbon with an i7-8550U CPU @ 1.8GHz). It's medium powered as far as ultrabooks go, but these numbers should really only be compared to each other. You should not try to extrapolate absolute performance on other hardware from here, although I would expect relative performance to stay pretty consistent. At a guess, CPU cache would have the biggest performance impact from hardware, and would benefit concatenation the most.

The central question I wanted to answer was: at what point is StringBuilder more efficient than string concatenation? But, as long as I was testing things, I thought I would add in String.Format and string interpolation just to see how much worse they are. I began by writing some very simple benchmark functions for each method, and then doing some sample runs. What I discovered right away is that StringBuilder obliterates every other method when you're doing hundreds of appends or more. In fact, I was honestly shocked by how much more efficient it was and it made me wonder if using longer strings would have an effect. Early tests were just appending strings of 2 or 3 characters at a time. I added a second append with a variable length (up to 20 characters in my test) to see what affect that had, and it evened things out a little bit, especially when doing only few total appends. However, that made the results less obvious as to what was happening, so I then wanted to remake the test functions so that each iteration performed only one append. The other thing I discovered quickly is that String.Format and string interpolation have nearly identical performance in terms of speed and memory use. So I dropped String.Format from later tests. And I was also surprised by how bad the performance is for interpolation. It made me wonder how String.Join performs. It performs great, as it turn out. Almost on par with StringBuilder. Below is the final design of the test functions.

Test Functions

public string Concat(int n, string l)
{
    var result = "";
    for (int i = 0; i < n; i++)
    {
        result += l;
    }

    return result;
}

public string Interpolation(int n, string l)
{
    var result = "";
    for (int i = 0; i < n; i++)
    {
        result = $"{result}{l}";
    }

    return result;
}

public string StringBuilder(int n, string l)
{
    StringBuilder sb = new StringBuilder("");
    for (int i = 0; i < n; i++)
    {
        sb.Append(l);
    }

    return sb.ToString();
}

public string Join(int n, string l)
{
    var list = Enumerable.Range(0, n).Select(i => l);
    return String.Join("", list);
}

The source is available on Github if you want to check it out for yourself and see everything in context.

Results

N = Number of append iterations; L = Length of substrings

Conclusions

StringBuilder is efficient at smaller scales than I thought, but it's still not clearly an improvement over concatenation until you're doing between 20 and 40 appends, depending on the size of the strings you're appending. StringBuilder is also basically pointless if the strings you're building are not already created; the work it takes to generate them will most likely wipe out any optimization you can do to assemble the final result.

So, should you use StringBuilder? Yes, sometimes. It depends on what your data is like, and what you're optimizing for. Basically, if you have large strings that you're concatenating only a few times, string concat may be more efficient in all criteria. If you're optimizing for memory, then Join has excellent memory efficiency for small strings, and comparable to StringBuilder for large ones. In any case, I think that 40 concats is a good rule of thumb break point for where you get clear performance benefits from StringBuilder regardless of what your data looks like.

But then that brings me to the actual heart of the matter. What are you doing that needs this kind of performance? Look at that chart again. All of these times are measured in nanoseconds. That's 1/1000 of a microsecond. Which is 1/1000 of a millisecond. Which is 1/1000 of a second. Do you really want to bother over a few billionths of a second? And so my real take-away advice here is to optimize for readability. If performance is a real world issue, then and only then should you optimize for performance.