StringBuilder: building long text efficiently

A CSV report of 8,000 rows built with += allocated 1,152.9 MB for a text of 144,000 chars, and a StringBuilder built the same text with 1.09 MB. The gap is not a constant: it grows with the report, because every += copies everything built so far.

You will see why that copying grows with the square of the length, build long text with a StringBuilder and its relatives, and count allocations yourself instead of guessing.

Adding to a string in a loop copies everything built so far

A string never changes, so csv += Row(i) cannot add a row to the end of csv. It makes a new string, copies the old text into it, adds the row, and leaves the old string to the garbage collector. This program builds the same report at four sizes and counts the bytes each one allocated:

// A CSV report of n rows built with += : every pass copies the whole report so far.
foreach (int rows in new[] { 1_000, 2_000, 4_000, 8_000 })
{
    long before = GC.GetAllocatedBytesForCurrentThread();
    string csv = "";
    for (int i = 0; i < rows; i++)
    {
        csv += Row(i);
    }
    long bytes = GC.GetAllocatedBytesForCurrentThread() - before;
    Console.WriteLine($"{rows,5} rows: {csv.Length,7} chars, {bytes / 1_000_000.0,7:F1} MB allocated with +=");
}

// Each row is 18 chars: an id, a seat, a fare and a line break.
static string Row(int i) => $"{100000 + i},S{i % 72:00},{450 + i % 9}.00\n";

 1000 rows:   18000 chars,    18.1 MB allocated with +=
 2000 rows:   36000 chars,    72.2 MB allocated with +=
 4000 rows:   72000 chars,   288.4 MB allocated with +=
 8000 rows:  144000 chars,  1152.9 MB allocated with +=

Each time the rows doubled, the bytes grew four times: 18.1, 72.2, 288.4 and 1,152.9 MB. Step through the passes to see where that comes from:

Pass k copies about k rows, so n passes copy about n²/2 rows. That is quadratic growthquadratic growth: Cost that grows with the square of the input: twice the input, four times the work. Building a string with += in a loop grows this way, because each pass copies everything built so far.: work that a 1,000-row report hardly notices takes over a gigabyte at 8,000 rows and would take 4.6 GB at 16,000. All of it is garbage the moment the next pass runs, so the program also keeps the garbage collector busy.

A StringBuilder appends into room it already has

A StringBuilderStringBuilder: System.Text.StringBuilder: a mutable buffer of chars with spare room. Append writes into the room, the buffer grows when it is full, and ToString() makes the finished string once. keeps its text in a buffer with spare room. Append writes into that room, and only when it is full does the builder allocate more, about doubling its capacity, without copying the text it already holds into a new string each time. ToString() makes the one final string at the end. The same report, built this way:

using System.Text;

// The same CSV report built with a StringBuilder, which appends into spare room.
foreach (int rows in new[] { 1_000, 2_000, 4_000, 8_000 })
{
    long before = GC.GetAllocatedBytesForCurrentThread();
    var sb = new StringBuilder();
    for (int i = 0; i < rows; i++)
    {
        sb.Append(Row(i));
    }
    string csv = sb.ToString();
    long bytes = GC.GetAllocatedBytesForCurrentThread() - before;
    Console.WriteLine($"{rows,5} rows: {csv.Length,7} chars, {bytes / 1_000_000.0,7:F2} MB allocated with StringBuilder");
}

// How the room grows: the capacity after each of the first appends of one row.
var watch = new StringBuilder();
Console.Write("Capacity after each append of 18 chars:");
for (int i = 0; i < 6; i++)
{
    watch.Append(Row(i));
    Console.Write($" {watch.Capacity}");
}
Console.WriteLine();

// Several + in one expression become one call to string.Concat.
string id = "100042", seat = "S07", fare = "457.00";
long start = GC.GetAllocatedBytesForCurrentThread();
string pair = id + "," + seat;
long three = GC.GetAllocatedBytesForCurrentThread() - start;
start = GC.GetAllocatedBytesForCurrentThread();
string row = id + "," + seat + "," + fare;
long five = GC.GetAllocatedBytesForCurrentThread() - start;
Console.WriteLine($"id + \",\" + seat                 \"{pair}\": {three} bytes, the new string alone");
Console.WriteLine($"id + \",\" + seat + \",\" + fare   \"{row}\": {five} bytes, the string and an array of the 5 parts");

static string Row(int i) => $"{100000 + i},S{i % 72:00},{450 + i % 9}.00\n";

 1000 rows:   18000 chars,    0.15 MB allocated with StringBuilder
 2000 rows:   36000 chars,    0.28 MB allocated with StringBuilder
 4000 rows:   72000 chars,    0.55 MB allocated with StringBuilder
 8000 rows:  144000 chars,    1.09 MB allocated with StringBuilder
Capacity after each append of 18 chars: 32 64 64 128 128 128
id + "," + seat                 "100042,S07": 48 bytes, the new string alone
id + "," + seat + "," + fare   "100042,S07,457.00": 120 bytes, the string and an array of the 5 parts

Now the bytes doubled when the rows doubled, 0.15, 0.28, 0.55 and 1.09 MB, and about half of that is the row strings that Row(i) makes for each line. The capacity line shows the room growing as the first rows went in: 32, 64, 64, 128, 128, 128. For an array or a list that already exists, string.Join(",", parts) and string.Concat(parts) do the same job in one call, measuring the parts first and copying each of them once.

One expression with a few parts costs one string

StringBuilder is not a better +. When one expression joins a few parts, as id + "," + seat does, the compiler turns it into a single call to string.Concat, which measures the parts and makes the result once, and a short interpolated string is likewise built in one buffer. The last two lines of builder.cs counted it: three parts allocated 48 bytes, the new string alone, and five parts 120 bytes, the string and an array of the five parts that Concat was given.

A StringBuilder for two or three parts adds an object and its buffer for nothing. The tool to reach for depends on whether the number of pieces is fixed or grows with the data.

Five ways to build one CSV, measured Pro: opens with a Pro, Premium or Ultimate pass

Appending formatted values without temporary strings Pro: opens with a Pro, Premium or Ultimate pass

Three builder mistakes that bring the cost back, reproduced Pro: opens with a Pro, Premium or Ultimate pass

Practise: a multiplication table

The questions below return to the 8,000-row report, the capacity line and the two concatenations. They open on the idea your answers show you know least, and every choice is explained with the numbers of these runs:

Interview questions

Fresher · Why is a StringBuilder faster than += for building a long string?

Because a string can never change, so s += part makes a new string and copies all the text built so far into it, every time. Over n appends that copying adds up to about n²/2 parts: twice the parts, four times the work. A StringBuilder keeps its text in a buffer with spare room and appends into it, growing the buffer only when it is full, so its work grows in step with the text, and ToString() makes the finished string once. Measured on .NET 10, a report of 8,000 rows took 1,152.9 MB of allocations with += and 1.09 MB with a builder. For a fixed handful of parts in one expression, + or an interpolated string is just as good, because the compiler makes one string.Concat call.

Key takeaways

• += in a loop copies everything built so far on every pass, so its work grows with the square of the length: four times the bytes when the rows double.
• A StringBuilder appends into spare room and makes one string with ToString(), so its cost grows in step with the length.
• string.Join and string.Concat build text from a collection in one call, and a few + in one expression are a single string.Concat.
• Count allocations with GC.GetAllocatedBytesForCurrentThread() before and after a change, instead of guessing.