Benchmarking StringBuilder and String.Concat with BenchmarkDotNet

When you join a session at the C# Corner Annual Conference 2020, the room is rarely quiet for long. Speakers in Sydney, Melbourne, Brisbane, Perth and Adelaide tune in to share real production code, not toy examples. Performance work is a recurring theme, and one of the questions that keeps surfacing across regions is whether StringBuilder still beats String.Concat once you have moved to .NET Core or .NET 5. The honest answer is that it depends on how many strings you are joining, how the JIT compiles your method, and what the underlying runtime does in the background.

String handling is one of those quiet costs that adds up inside Australian businesses running line-of-business systems. A payroll batch that loops over thousands of payslips, a reporting service that assembles CSV rows, or a reconciliation job for a fintech will spend a surprising share of its wall-clock time gluing strings together. If you have ever profiled a sluggish batch in Visual Studio and seen String.Concat or Append calls dominating the CPU, the next question is always the same: which approach is fastest, and by how much.

Rather than guessing, the .NET community has a tool that turns the question into measurable evidence: BenchmarkDotNet. The library is open source, runs on Windows, Linux and macOS, and produces statistical summaries that engineers can defend in a code review. You point it at a method, it warms up the JIT, runs hundreds of iterations, throws away outliers and reports mean, median and standard deviation. For a developer preparing a conference talk or a tech blog post, it is the standard way to back up a claim with numbers.

This walk-through uses BenchmarkDotNet to put StringBuilder and String.Concat side by side across several realistic workloads. The goal is not to crown a universal winner but to understand the conditions under which each approach wins, so the next time you are refactoring a hot loop in a service hosted through the National Broadband Network or a cloud region in Sydney, you can make a deliberate choice.

Why string assembly performance still matters in modern .NET

The .NET runtime has changed a great deal since the early Framework days. Modern versions perform aggressive inlining, devirtualisation and even a few allocations through String.Concat overloads that accept up to four arguments. The compiler can collapse a chain of + operators into a single String.Concat call. That means the old rule of thumb, "StringBuilder for every loop, no exceptions," no longer holds in every situation, and benchmarks that ran on .NET Framework 4.x do not always translate to current runtimes.

For developers in Australia working on government-facing systems, performance also ties back to the Privacy Act 1988 and the Notifiable Data Breaches scheme. Slower batch processes can mean longer windows where sensitive data sits in memory, and a faster, more deterministic string assembly path can reduce that exposure slightly. While the legislation does not dictate which collection class you use, it does push engineering teams towards leaner pipelines that minimise the time data lingers in process memory.

There is also a commercial angle. Independent software vendors in Brisbane and Melbourne often host their workloads in Australian Azure regions, and cloud bills are sensitive to CPU time. A service that cuts its string assembly time in half during a peak event such as EOFY reporting or end-of-month invoicing can shave measurable dollars off the monthly invoice. The wins are rarely large, but they compound across microservices and across years of operation.

Performance is also a literacy issue. Junior developers joining a .NET user group in Adelaide or a DDD Melbourne meetup often arrive with muscle memory from Java or older C# code. Showing them how to set up a BenchmarkDotNet project, run it, and read the results gives them a tool they will reuse for years, on topics far beyond string handling.

Setting up BenchmarkDotNet inside a .NET project

A benchmark project is just a console application with one extra NuGet package. Create a new project, add BenchmarkDotNet from NuGet, and the [Benchmark] attribute becomes available alongside the existing dotnet tooling. There is no special Visual Studio extension required, although the IDE integrates nicely with the generated summaries.

Once the package is referenced, you mark a class with [MemoryDiagnoser] and [Orderer(SummaryOrderPolicy.FastestToSlowest)] to get allocation and timing data in a single run. The attribute-based approach means you can write a benchmark that looks almost like a normal unit test, which is helpful for engineers who already run xUnit suites on a CI runner sitting in the Asia-Pacific region with AEDT clocks.

It is worth checking your environment before you trust the numbers. BenchmarkDotNet expects the machine to be otherwise idle, with consistent power settings. On a laptop in Sydney during summer, that can be a challenge, because thermal throttling under air conditioning often hides the true difference between fast paths. Many Australian developers set up a dedicated runner in a server room or pin the benchmark to a cloud VM with a fixed CPU type. The library will warn you if it detects noisy conditions, and you should respect that warning rather than publish the results anyway.

A practical touch for any Australian team is to record the time zone in the run output. Benchmarks that run in AEDT during daylight saving or AEST outside of it will produce different absolute numbers from runs in Seattle, so include the environment details when you write up the findings. The tool has a [ShortRunJob] for quick local checks and a default mode that runs for several minutes. Use the short job while iterating, and the default job when you want a defensible measurement.

Designing benchmark methods that produce fair results

A benchmark is only as good as the methods it measures. For a fair StringBuilder versus String.Concat comparison, the inputs have to be identical, the loop counts have to match, and the output should be touched so the optimiser does not eliminate the work. A common mistake is to write a method that returns the built string, while the alternative returns something the JIT can prove is unused. The result is a comparison that is really measuring dead-code elimination.

A useful pattern is to build a small array of inputs that mimics your real workload. For a CSV row you might have ten fields; for an invoice line you might have three or four; for a URL builder you might have six. Run each benchmark with the same array and the same iteration count, and assign the result to a class-level field to keep the value alive. The [MemoryDiagnoser] attribute will then show you both time and bytes allocated, which is often the deciding factor on a memory-constrained environment such as a small Azure App Service plan in a secondary Australian region.

You can also vary the iteration count to see how the comparison shifts. With very small counts, the cost of constructing a StringBuilder instance can outweigh any benefit, and String.Concat wins. As the count grows, StringBuilder starts to pull ahead because it avoids allocating intermediate strings on each append. That crossover point is the interesting story for your audience, because it tells them when to switch approaches.

For readers building a side project at home in Perth or working on a startup in Adelaide, the same project can host multiple benchmark classes. You can write one class that compares a tight loop of ten iterations, another that compares one hundred, and a third that compares ten thousand. The same class can also include a string.Format and an interpolated string variant, giving you a four-way comparison from a single dotnet run.

Reading the BenchmarkDotNet output like an engineer

When the run finishes, BenchmarkDotNet prints a Markdown-friendly table with mean, standard deviation, allocated bytes and Gen 0, 1 and 2 collections. For a C# Corner session you can paste that table directly into your slides. For an internal wiki you can also export to CSV and chart it in Power BI, which is useful when you are presenting to a product owner in a Melbourne office and want a visual rather than a wall of numbers.

The first number to look at is allocated bytes, not nanoseconds. Allocations drive garbage collection, and on a service that handles a steady stream of requests, Gen 0 collections can show up as latency spikes long before CPU time becomes a problem. A StringBuilder that ends up growing its buffer several times can allocate more bytes than a single String.Concat call, which is why the smallest mean time does not always mean the lowest memory pressure.

The second number to look at is the ratio column. BenchmarkDotNet compares each method to a baseline and reports something like 1.15 or 0.87. A ratio above one means slower, below one means faster. The column is invaluable when you are presenting to stakeholders who do not care about nanoseconds but do care about whether the change is a two-percent tweak or a fifty-percent win.

Finally, watch the standard deviation. A benchmark that reports a mean of 80ns with a standard deviation of 60ns is not really telling you anything, because the noise is comparable to the signal. The library will highlight this in its summary and suggest a longer run. For a conference talk, you want mean values whose standard deviation is below ten percent of the mean, otherwise the audience will rightly challenge the conclusion.

Picking the right tool for the job in everyday code

After running the benchmarks, the practical advice is short and easy to remember. Use String.Concat, or simply + with a handful of pieces, when the input is fixed, small and known at compile time. Use StringBuilder when you are inside a loop, when the input count is dynamic, or when you need explicit control over capacity. The benchmarks will confirm this rule, and they will also show you the exact crossover point for your own hardware.

A common follow-up question is whether interpolated strings change the picture. Under the hood, the C# compiler lowers an interpolated string to either String.Format or String.Concat, depending on the form. A simple interpolation such as $"{a}-{b}-{c}" is usually lowered to a String.Concat call, so it competes with the static method rather than with StringBuilder. A composite format string with many placeholders falls back to String.Format and is generally the slowest of the three, although it is also the most readable.

The other thing to remember is that hot paths are rare. Most string assembly in a typical business application happens during logging, request shaping or response rendering, and the absolute time spent there is dwarfed by database and network waits. Optimising the wrong place is a familiar trap for engineers in fast-growing teams in Brisbane, where the pressure to ship features can push performance work to the back of the queue. A targeted benchmark, run once and filed in the wiki, prevents the same debate from being relit every code review.

Practical recommendations before you ship the next release

• Add BenchmarkDotNet to a small console project in your solution and keep it in source control so anyone can re-run the numbers on the same hardware.
• Always include [MemoryDiagnoser]; allocation data is often more actionable than raw time, especially for long-running services.
• Pin your environment, log the time zone (AEST or AEDT) and the CPU model, and avoid laptops under thermal pressure when you need trustworthy numbers.
• Test at least three iteration counts, because the fastest method often changes between very small and very large loops.
• Treat the output as a starting point and profile the real production path with dotnet-trace or the Visual Studio profiler before investing in a rewrite.