Another look at benchmarks

A little over two and a half years ago, I have a blog post investigating the difference in the memory footprint between the use of StringBuilder and general string concatenation.  The version of BenchmarkDotNet that I used was v0.10.2 and I used Framework 4.6.  Now is a good time to retry using the latest in both, v0.12.0 and .NET Core 3.0.  So, let's start a new project based on Console App (.NET Core) and name it as before:

Then let's add the BenchmarkDotNet NuGet package:

And accept the changes:

Add the source from the previous article and give it a run by changing into your directory and run via dotnet StringsVSStringBuilder in an administrative command prompt:

When it runs, you will notice that the first thing that it does is compile the benchmark.  That is different than what the previous version did, but it isn't really surprising.  It makes sense to compile the application into a known state, and the tooling has come a long way.

Looking at the results, we find that we need to do a bit more to get the memory output that we are looking for in this instance:

The MemoryDiagnoser is no longer enabled by default:

Let's add it via an attribute on the test class:

Now, running the tests again and we get the memory output again:

As before, the concat method allocated a little more than twice the memory of that of the StringBuilder version.  It is also a small, but significant bit faster.