{"id":17335,"date":"2018-04-18T12:29:45","date_gmt":"2018-04-18T19:29:45","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/dotnet\/?p=17335"},"modified":"2025-10-29T11:06:43","modified_gmt":"2025-10-29T18:06:43","slug":"performance-improvements-in-net-core-2-1","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/performance-improvements-in-net-core-2-1\/","title":{"rendered":"Performance Improvements in .NET Core 2.1"},"content":{"rendered":"

Back before .NET Core 2.0 shipped, I wrote a post<\/a> highlighting various performance improvements in .NET Core 2.0 when compared with .NET Core 1.1 and the .NET Framework. As .NET Core 2.1 is in its final stages of being released, I thought it would be a good time to have some fun and take a tour through some of the myriad of performance improvements that have found their way into this release.<\/p>\n

Performance improvements show up in .NET Core 2.1 in a variety of ways. One of the big focuses of the release has been on the new System.Span<T><\/code> type that, along with its friends like System.Memory<T><\/code>, are now at the heart of the runtime and core libraries (see this MSDN Magazine article<\/a> for an introduction). New libraries have been added in this release, like System.Memory.dll<\/a>, System.Threading.Channels.dll<\/a>, and System.IO.Pipelines.dll<\/a>, each targeted at specific scenarios. And many new members have been added to existing types, for example ~250 new members across existing types in the framework that accept or return the new span and memory types, and counting members on new types focusing on working with span and memory more than doubles that (e.g. the new BinaryPrimitives<\/code> and Utf8Formatter<\/code> types). All such improvements are worthy of their own focused blog posts, but they’re not what I’m focusing on here. Rather, I’m going to walk through some of the myriad of improvements that have been made to existing functionality, to existing types and methods, places where you upgrade a library or app from .NET Core 2.0 to 2.1 and performance just gets better. For the purposes of this post, I\u2019m focused primarily on the runtime<\/a> and the core libraries<\/a>, but there have also been substantial performance improvements higher in the stack, as well as in tooling.<\/p>\n

<\/a>Setup<\/h4>\n

In my post on .NET Core 2.0 performance<\/a>, I demonstrated improvements using simple console apps with custom measurement loops, and I got feedback that readers would have preferred if it if I’d used a standard benchmarking tool. While I explicitly opted not to do so then (the reason being making it trivial for developers to follow along by copying and pasting code samples into their own console apps), this time around I decided to experiment with the approach, made easier by tooling improvements in the interim. So, to actually run the complete code samples shown in this post, you’ll need a few things. In my setup, I have both .NET Core 2.0 and a preview of .NET Core 2.1 installed. I then did dotnet new console<\/code>, and modified the resulting .csproj as follows, which includes specifying both releases as target frameworks and including a package reference for Benchmark.NET<\/a>, used to do the actual benchmarking.<\/p>\n