{"id":23254,"date":"2019-05-15T12:17:00","date_gmt":"2019-05-15T19:17:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/dotnet\/?p=23254"},"modified":"2025-10-29T11:06:47","modified_gmt":"2025-10-29T18:06:47","slug":"performance-improvements-in-net-core-3-0","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/dotnet\/performance-improvements-in-net-core-3-0\/","title":{"rendered":"Performance Improvements in .NET Core 3.0"},"content":{"rendered":"

Back when we were getting ready to ship .NET Core 2.0, I wrote a\u00a0blog post<\/a>\u00a0exploring some of the many performance improvements that had gone into it. I enjoyed putting it together so much and received such a positive response to the post that I did it\u00a0again for .NET Core 2.1<\/a>, a version for which performance was also a significant focus. With \/\/build<\/a> last week and .NET Core 3.0<\/a>‘s release now on the horizon, I’m thrilled to have an opportunity to do it again. .NET Core 3.0 has a ton to offer, from Windows Forms and WPF, to single-file executables, to async enumerables, to platform intrinsics, to HTTP\/2, to fast JSON reading and writing, to assembly unloadability, to enhanced cryptography, and on and on and on… there is a wealth of new functionality to get excited about. For me, however, performance is the primary feature that makes me excited to go to work in the morning, and there’s a staggering amount of performance goodness in .NET Core 3.0. In this post, we’ll take a tour through some of the many improvements, big and small, that have gone into the .NET Core runtime and core libraries in order to make your apps and services leaner and faster.<\/p>\n

Setup<\/h3>\n

Benchmark.NET<\/a>\u00a0has become the preeminent tool for doing benchmarking of .NET libraries, and so as I did in my 2.1 post, I’ll use Benchmark.NET to demonstrate the improvements. Throughout the post, I’ll include the individual snippets of benchmarks that highlight the particular improvement being discussed. To be able to execute those benchmarks, you can use the following setup: 1. Ensure you have\u00a0.NET Core 3.0<\/a>\u00a0installed, as well as\u00a0.NET Core 2.1<\/a>\u00a0for comparison purposes. 2. Create a directory named\u00a0BlogPostBenchmarks<\/code>. 3. In that directory, run\u00a0dotnet new console<\/code>. 4. Replace the contents of BlogPostBenchmarks.csproj with the following:<\/p>\n

<Project Sdk=\"Microsoft.NET.Sdk\">\n\n  <PropertyGroup>\n    <OutputType>Exe<\/OutputType>\n    <AllowUnsafeBlocks>true<\/AllowUnsafeBlocks>\n    <TargetFrameworks>netcoreapp2.1;netcoreapp3.0<\/TargetFrameworks>\n  <\/PropertyGroup>\n\n  <ItemGroup>\n    <PackageReference Include=\"BenchmarkDotNet\" Version=\"0.11.5\" \/>\n    <PackageReference Include=\"System.Drawing.Common\" Version=\"4.5.0\" \/>\n    <PackageReference Include=\"System.IO.Pipelines\" Version=\"4.5.0\" \/>\n    <PackageReference Include=\"System.Threading.Channels\" Version=\"4.5.0\" \/>\n  <\/ItemGroup>\n\n<\/Project><\/pre>\n
    \n
  1. Replace the contents of Program.cs with the following: <\/li>\n<\/ol>\n
    using BenchmarkDotNet.Attributes;\nusing BenchmarkDotNet.Configs;\nusing BenchmarkDotNet.Jobs;\nusing BenchmarkDotNet.Running;\nusing BenchmarkDotNet.Toolchains.CsProj;\nusing Microsoft.Win32.SafeHandles;\nusing System;\nusing System.Buffers;\nusing System.Collections;\nusing System.Collections.Concurrent;\nusing System.Collections.Generic;\nusing System.Collections.Immutable;\nusing System.Diagnostics;\nusing System.Drawing;\nusing System.Drawing.Drawing2D;\nusing System.Globalization;\nusing System.IO;\nusing System.IO.Compression;\nusing System.IO.Pipelines;\nusing System.Linq;\nusing System.Net;\nusing System.Net.Http;\nusing System.Net.NetworkInformation;\nusing System.Net.Security;\nusing System.Net.Sockets;\nusing System.Runtime.CompilerServices;\nusing System.Runtime.InteropServices;\nusing System.Security.Authentication;\nusing System.Security.Cryptography.X509Certificates;\nusing System.Text;\nusing System.Text.RegularExpressions;\nusing System.Threading;\nusing System.Threading.Channels;\nusing System.Threading.Tasks;\nusing System.Xml;\n\n[MemoryDiagnoser]\npublic class Program\n{\n    static void Main(string[] args) => BenchmarkSwitcher.FromTypes(new[] { typeof(Program) }).Run(args);\n\n    \/\/ ... paste benchmark code here\n}<\/pre>\n
    To execute a particular benchmark, unless otherwise noted, copy and paste the relevant code to replace the\u00a0<\/p>\n
    \/\/ ...<\/code>above, and execute\u00a0dotnet run -c Release -f netcoreapp2.1 --runtimes netcoreapp2.1 netcoreapp3.0 --filter \"*Program*\"<\/code>. This will compile and run the tests in release builds, on both .NET Core 2.1 and .NET Core 3.0, and print out the results for comparison in a table.<\/p>\n
    Caveats A few caveats before we get started:<\/h3>\n
      \n
    1. Any discussion involving microbenchmark results deserves a caveat that measurements can and do vary from machine to machine. I’ve tried to pick stable examples to share (and have run these tests on multiple machines in multiple configurations to help validate that), but don’t be too surprised if your numbers differ from the ones I’ve shown; hopefully, however, the magnitude of the improvements demonstrated carries through. All of the shown results are from a nightly Preview 6 build for .NET Core 3.0. Here’s my configuration, as summarized by Benchmark.NET, on my Windows configuration and on my Linux configuration: <\/li>\n<\/ol>\n
      BenchmarkDotNet=v0.11.5, OS=Windows 10.0.17763.437 (1809\/October2018Update\/Redstone5)\nIntel Core i7-7660U CPU 2.50GHz (Kaby Lake), 1 CPU, 4 logical and 2 physical cores\n.NET Core SDK=3.0.100-preview6-011854\n  [Host]     : .NET Core 2.1.9 (CoreCLR 4.6.27414.06, CoreFX 4.6.27415.01), 64bit RyuJIT\n  Job-RODBZD : .NET Core 2.1.9 (CoreCLR 4.6.27414.06, CoreFX 4.6.27415.01), 64bit RyuJIT\n  Job-TVOWAH : .NET Core 3.0.0-preview6-27712-03 (CoreCLR 3.0.19.26071, CoreFX 4.700.19.26005), 64bit RyuJIT\n\nBenchmarkDotNet=v0.11.5, OS=ubuntu 18.04\nIntel Xeon CPU E5-2673 v4 2.30GHz, 1 CPU, 4 logical and 2 physical cores\n.NET Core SDK=3.0.100-preview6-011877\n  [Host]     : .NET Core 2.1.10 (CoreCLR 4.6.27514.02, CoreFX 4.6.27514.02), 64bit RyuJIT\n  Job-SSHMNT : .NET Core 2.1.10 (CoreCLR 4.6.27514.02, CoreFX 4.6.27514.02), 64bit RyuJIT\n  Job-CHXNFO : .NET Core 3.0.0-preview6-27713-12 (CoreCLR 3.0.19.26071, CoreFX 4.700.19.26307), 64bit RyuJIT<\/pre>\n
        \n
      1. Unless otherwise mentioned, benchmarks were executed on Windows. In many cases, performance is equivalent between Windows and Unix, but in others, there can be non-trivial discrepancies between them, in particular in places where .NET relies on OS functionality, and the OS itself has different performance characteristics.<\/li>\n
      2. I mentioned posts on .NET Core 2.0 and .NET Core 2.1, but I didn’t mention .NET Core 2.2. .NET Core 2.2 was primarily focused on ASP.NET, and while there were terrific performance improvements at the ASP.NET layer in 2.2, the release was primarily focused on servicing for the runtime and core libraries, with most improvements post-2.1 skipping 2.2 and going into 3.0. With that out of the way, let’s have some fun. <\/li>\n<\/ol>\n
        Span and Friends<\/h3>\n
        One of the more notable features introduced in .NET Core 2.1 was\u00a0Span<T><\/code>, along with its friends\u00a0ReadOnlySpan<T><\/code>,\u00a0Memory<T><\/code>, and\u00a0ReadOnlyMemory<T><\/code>. The introduction of these new types came with hundreds of new methods for interacting with them, some on new types and some with overloaded functionality on existing types, as well as optimizations in the just-in-time compiler (JIT) for making working with them very efficient. The release also included some internal usage of\u00a0Span<T><\/code>\u00a0to make existing operations leaner and faster while still enjoying maintainable and safe code. In .NET Core 3.0, much additional work has gone into further improving all such aspects of these types: making the runtime better at generating code for them, increasing the use of them internally to help improve many other operations, and improving the various library utilities that interact with them to make consumption of these operations faster. To work with a span, one first needs to get a span, and several PRs have made doing so faster. In particular, passing around a\u00a0Memory<T><\/code>\u00a0and then getting a\u00a0Span<T><\/code>\u00a0from it is a very common way of creating a span; this is, for example, how the various\u00a0Stream.WriteAsync<\/code>\u00a0and\u00a0ReadAsync<\/code>\u00a0methods work, accepting a\u00a0{ReadOnly}Memory<T><\/code>\u00a0(so that it can be stored on the heap) and then accessing its\u00a0Span<\/code>\u00a0property once the actual bytes need to be read or written. PR\u00a0dotnet\/coreclr#20771<\/a>\u00a0improved this by removing an argument validation branch (both for\u00a0{ReadOnly}Memory<T>.Span<\/code>\u00a0and for\u00a0{ReadOnly}Span<T>.Slice<\/code>), and while removing a branch is a small thing, in span-heavy code (such as when doing formatting and parsing), small things done over and over and over again add up. More impactful, PR\u00a0dotnet\/coreclr#20386<\/a>\u00a0plays tricks at the runtime level to safely eliminate some of the runtime checked casting and bit masking logic that had been used to enable\u00a0{ReadOnly}Memory<T><\/code>\u00a0to wrap various types, like\u00a0string<\/code>,\u00a0T[]<\/code>, and\u00a0MemoryManager<T><\/code>, providing a seamless veneer over all of them. The net result of these PRs is a nice speed-up when fishing a\u00a0Span<T><\/code>\u00a0out of a\u00a0Memory<T><\/code>, which in turn improves all other operations that do so.<\/p>\n
        private ReadOnlyMemory<byte> _mem = new byte[1];\n\n[Benchmark]\npublic ReadOnlySpan<byte> GetSpan() => _mem.Span;<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        GetSpan\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        3.873 ns\n      <\/td>\n\n        0.0927 ns\n      <\/td>\n\n        0.0822 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        GetSpan\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        1.843 ns\n      <\/td>\n\n        0.0401 ns\n      <\/td>\n\n        0.0375 ns\n      <\/td>\n\n        0.48\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Of course, once you get a span, you want to use it, and there are a myriad of ways to use one, many of which have also been optimized further in .NET Core 3.0. For example, just as with arrays, to pass the data from a span to native code via a P\/Invoke, the data needs to be pinned (unless it’s already immovable, such as if the span were created to wrap some natively allocated memory not on the GC heap or if it were created for some data on the stack). To pin a span, the easiest way is to simply rely on the C# language’s support added in C# 7.3 that supports a pattern-based way to use any type with the\u00a0<\/p>\n
        fixed<\/code>\u00a0keyword. All a type need do is expose a\u00a0GetPinnableReference<\/code>\u00a0method (or extension method) that returns a\u00a0ref T<\/code>\u00a0to the data stored in that instance, and that type can be used with\u00a0fixed<\/code>.\u00a0{ReadOnly}Span<T><\/code>\u00a0does exactly this. However, even though\u00a0{ReadOnly}Span<T>.GetPinnableReference<\/code>\u00a0generally gets inlined, a call it makes internally to\u00a0Unsafe.AsRef<\/code>\u00a0was getting blocked from inlining; PR\u00a0dotnet\/coreclr#18274<\/a>\u00a0fixed this, enabling the whole operation to be inlined. Further, the aforementioned code was actually tweaked in PR\u00a0dotnet\/coreclr#20428<\/a>\u00a0to eliminate one branch on the hot path. Both of these combine to result in a measurable boost when pinning a span:<\/p>\n
        private readonly byte[] _bytes = new byte[10_000];\n\n[Benchmark(OperationsPerInvoke = 10_000)]\npublic unsafe int PinSpan()\n{\n    Span<byte> s = _bytes;\n    int total = 0;\n\n    for (int i = 0; i < s.Length; i++)\n        fixed (byte* p = s) \/\/ equivalent to `fixed (byte* p = &s.GetPinnableReference())`\n            total += *p;\n\n    return total;\n}<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        RatioSD\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        PinSpan\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        0.7930 ns\n      <\/td>\n\n        0.0177 ns\n      <\/td>\n\n        0.0189 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        PinSpan\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        0.6496 ns\n      <\/td>\n\n        0.0109 ns\n      <\/td>\n\n        0.0102 ns\n      <\/td>\n\n        0.82\n      <\/td>\n\n        0.03\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 It’s worth noting, as well, that if you’re interested in these kinds of micro-optimizations, you might also want to avoid using the default pinning at all, at least on super hot paths. The\u00a0<\/p>\n
        {ReadOnly}Span<T>.GetPinnableReference<\/code>\u00a0method was designed to behave just like pinning of arrays and strings, where null or empty inputs result in a null pointer. This behavior requires an additional check to be performed to see whether the length of the span is zero:<\/p>\n
        \/\/ https:\/\/github.com\/dotnet\/coreclr\/blob\/52aff202cd382c233d903d432da06deffaa21868\/src\/System.Private.CoreLib\/shared\/System\/Span.Fast.cs#L168-L174\n\n[EditorBrowsable(EditorBrowsableState.Never)]\npublic unsafe ref T GetPinnableReference()\n{\n    \/\/ Ensure that the native code has just one forward branch that is predicted-not-taken.\n    ref T ret = ref Unsafe.AsRef<T>(null);\n    if (_length != 0) ret = ref _pointer.Value;\n    return ref ret;\n}<\/pre>\n
        If in your code by construction you know that the span will not be empty, you can choose to instead use\u00a0<\/p>\n
        MemoryMarshal.GetReference<\/code>, which performs the same operation but without the length check:<\/p>\n
        \/\/ https:\/\/github.com\/dotnet\/coreclr\/blob\/52aff202cd382c233d903d432da06deffaa21868\/src\/System.Private.CoreLib\/shared\/System\/Runtime\/InteropServices\/MemoryMarshal.Fast.cs#L79\n\npublic static ref T GetReference<T>(Span<T> span) => ref span._pointer.Value;<\/pre>\n
        Again, while a single check adds minor overhead, when executed over and over and over, that can add up:<\/p>\n
        private readonly byte[] _bytes = new byte[10_000];\n\n[Benchmark(OperationsPerInvoke = 10_000, Baseline = true)]\npublic unsafe int PinSpan()\n{\n    Span<byte> s = _bytes;\n    int total = 0;\n\n    for (int i = 0; i < s.Length; i++)\n        fixed (byte* p = s) \/\/ equivalent to `fixed (byte* p = &s.GetPinnableReference())`\n            total += *p;\n\n    return total;\n}\n\n[Benchmark(OperationsPerInvoke = 10_000)]\npublic unsafe int PinSpanExplicit()\n{\n    Span<byte> s = _bytes;\n    int total = 0;\n\n    for (int i = 0; i < s.Length; i++)\n        fixed (byte* p = &MemoryMarshal.GetReference(s))\n            total += *p;\n\n    return total;\n}<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        RatioSD\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        PinSpan\n      <\/td>\n\n        0.6524 ns\n      <\/td>\n\n        0.0129 ns\n      <\/td>\n\n        0.0159 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        PinSpanExplicit\n      <\/td>\n\n        0.5200 ns\n      <\/td>\n\n        0.0111 ns\n      <\/td>\n\n        0.0140 ns\n      <\/td>\n\n        0.80\n      <\/td>\n\n        0.03\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Of course, there are many other (and generally preferred) ways to operate over a span’s data than to use\u00a0<\/p>\n
        fixed<\/code>. For example, it’s a bit surprising that until\u00a0Span<T><\/code>\u00a0came along, .NET didn’t have a built-in equivalent of\u00a0memcmp<\/code>, but nevertheless,\u00a0Span<T><\/code>‘s\u00a0SequenceEqual<\/code>\u00a0and\u00a0SequenceCompareTo<\/code>\u00a0methods have become go-to methods for comparing in-memory data in .NET. In .NET Core 2.1, both\u00a0SequenceEqual<\/code>\u00a0and\u00a0SequenceCompareTo<\/code>\u00a0were optimized to utilize\u00a0System.Numerics.Vector<\/code>\u00a0for vectorization, but the nature of\u00a0SequenceEqual<\/code>\u00a0made it more amenable to best take advantage. In PR\u00a0dotnet\/coreclr#22127<\/a>, @benaadams updated\u00a0SequenceCompareTo<\/code>\u00a0to take advantage of the new hardware instrinsics APIs available in .NET Core 3.0 to specifically target AVX2 and SSE2, resulting in significant improvements when comparing both small and large spans. (For more information on hardware intrinsics in .NET Core 3.0, see\u00a0platform-intrinsics.md<\/a>\u00a0and\u00a0using-net-hardware-intrinsics-api-to-accelerate-machine-learning-scenarios<\/a>.)<\/p>\n
        private byte[] _orig, _same, _differFirst, _differLast;\n\n[Params(16, 256)]\npublic int Length { get; set; }\n\n[GlobalSetup]\npublic void Setup()\n{\n    _orig = Enumerable.Range(0, Length).Select(i => (byte)i).ToArray();\n    _same = (byte[])_orig.Clone();\n\n    _differFirst = (byte[])_orig.Clone();\n    _differFirst[0] = (byte)(_orig[0] + 1);\n\n    _differLast = (byte[])_orig.Clone();\n    _differLast[_differLast.Length - 1] = (byte)(_orig[_orig.Length - 1] + 1);\n}\n\n[Benchmark]\npublic int CompareSame() => _orig.AsSpan().SequenceCompareTo(_same);\n\n[Benchmark]\npublic int CompareDifferFirst() => _orig.AsSpan().SequenceCompareTo(_differFirst);\n\n[Benchmark]\npublic int CompareDifferLast() => _orig.AsSpan().SequenceCompareTo(_differLast);<\/pre>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Length\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        CompareSame\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        16\n      <\/td>\n\n        16.955 ns\n      <\/td>\n\n        0.2009 ns\n      <\/td>\n\n        0.1781 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CompareSame\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        16\n      <\/td>\n\n        4.757 ns\n      <\/td>\n\n        0.0938 ns\n      <\/td>\n\n        0.0732 ns\n      <\/td>\n\n        0.28\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        CompareDifferFirst\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        16\n      <\/td>\n\n        11.874 ns\n      <\/td>\n\n        0.1240 ns\n      <\/td>\n\n        0.1100 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CompareDifferFirst\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        16\n      <\/td>\n\n        5.174 ns\n      <\/td>\n\n        0.0543 ns\n      <\/td>\n\n        0.0508 ns\n      <\/td>\n\n        0.44\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        CompareDifferLast\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        16\n      <\/td>\n\n        16.644 ns\n      <\/td>\n\n        0.2146 ns\n      <\/td>\n\n        0.2007 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CompareDifferLast\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        16\n      <\/td>\n\n        5.373 ns\n      <\/td>\n\n        0.0479 ns\n      <\/td>\n\n        0.0448 ns\n      <\/td>\n\n        0.32\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        CompareSame\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        256\n      <\/td>\n\n        43.740 ns\n      <\/td>\n\n        0.8226 ns\n      <\/td>\n\n        0.7292 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CompareSame\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        256\n      <\/td>\n\n        11.055 ns\n      <\/td>\n\n        0.1625 ns\n      <\/td>\n\n        0.1441 ns\n      <\/td>\n\n        0.25\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        CompareDifferFirst\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        256\n      <\/td>\n\n        12.144 ns\n      <\/td>\n\n        0.0849 ns\n      <\/td>\n\n        0.0752 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CompareDifferFirst\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        256\n      <\/td>\n\n        6.663 ns\n      <\/td>\n\n        0.1044 ns\n      <\/td>\n\n        0.0977 ns\n      <\/td>\n\n        0.55\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        CompareDifferLast\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        256\n      <\/td>\n\n        39.697 ns\n      <\/td>\n\n        0.9291 ns\n      <\/td>\n\n        2.6054 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CompareDifferLast\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        256\n      <\/td>\n\n        11.242 ns\n      <\/td>\n\n        0.2218 ns\n      <\/td>\n\n        0.1732 ns\n      <\/td>\n\n        0.32\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 As background, “vectorization” is an approach to parallelization that performs multiple operations as part of individual instructions on a single core. Some optimizing compilers can perform automatic vectorization, whereby the compiler analyzes loops to determine whether it can generate functionally equivalent code that would utilize such instructions to run faster. The .NET JIT compiler does not currently perform auto-vectorization, but it is possible to manually vectorize loops, and the options for doing so have significantly improved in .NET Core 3.0. Just as a simple example of what vectorization can look like, imagine having an array of bytes and wanting to search it for the first non-zero byte, returning the position of that byte. The simple solution is to just iterate through all of the bytes:<\/p>\n
        private byte[] _buffer = new byte[10_000].Concat(new byte[] { 42 }).ToArray();\n\n[Benchmark(Baseline = true)]\npublic int LoopBytes()\n{\n    byte[] buffer = _buffer;\n    for (int i = 0; i < buffer.Length; i++)\n    {\n        if (buffer[i] != 0)\n            return i;\n    }\n    return -1;\n}<\/pre>\n
        That of course works functionally, and for very small arrays it’s fine. But for larger arrays, we end up doing significantly more work than is actually necessary. Consider instead in a 64-bit process re-interpreting the array of bytes as an array of longs, which\u00a0<\/p>\n
        Span<T><\/code>\u00a0nicely supports. We then effectively compare 8 bytes at a time rather than 1 byte at a time, at the expense of added code complexity: once we find a non-zero long, we then need to look at each byte it contains to determine the position of the first non-zero one (though there are ways to improve that, too). Similarly, the array’s length may not evenly divide by 8, so we need to be able to handle the overflow.<\/p>\n
        [Benchmark]\npublic int LoopLongs()\n{\n    byte[] buffer = _buffer;\n    int remainingStart = 0;\n\n    if (IntPtr.Size == sizeof(long))\n    {\n        Span<long> longBuffer = MemoryMarshal.Cast<byte, long>(buffer);\n        remainingStart = longBuffer.Length * sizeof(long);\n\n        for (int i = 0; i < longBuffer.Length; i++)\n        {\n            if (longBuffer[i] != 0)\n            {\n                remainingStart = i * sizeof(long);\n                break;\n            }\n        }\n    }\n\n    for (int i = remainingStart; i < buffer.Length; i++)\n    {\n        if (buffer[i] != 0)\n            return i;\n    }\n\n    return -1;\n}<\/pre>\n
        For longer arrays, this yields really nice wins:<\/p>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        LoopBytes\n      <\/td>\n\n        5,462.3 ns\n      <\/td>\n\n        107.093 ns\n      <\/td>\n\n        105.180 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        LoopLongs\n      <\/td>\n\n        568.6 ns\n      <\/td>\n\n        6.895 ns\n      <\/td>\n\n        5.758 ns\n      <\/td>\n\n        0.10\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 I’ve glossed over some details here, but it should convey the core idea. .NET includes additional mechanisms for vectorizing as well. In particular, the aforementioned\u00a0<\/p>\n
        System.Numerics.Vector<\/code>\u00a0type allows for a developer to write code using\u00a0Vector<\/code>\u00a0and then have the JIT compiler translate that into the best instructions available on the current platform.<\/p>\n
        [Benchmark]\npublic int LoopVectors()\n{\n    byte[] buffer = _buffer;\n    int remainingStart = 0;\n\n    if (Vector.IsHardwareAccelerated)\n    {\n        while (remainingStart <= buffer.Length - Vector<byte>.Count)\n        {\n            var vector = new Vector<byte>(buffer, remainingStart);\n            if (!Vector.EqualsAll(vector, default))\n            {\n                break;\n            }\n            remainingStart += Vector<byte>.Count;\n        }\n    }\n\n    for (int i = remainingStart; i < buffer.Length; i++)\n    {\n        if (buffer[i] != 0)\n            return i;\n    }\n\n    return -1;\n}<\/pre>\n\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        LoopBytes\n      <\/td>\n\n        5,462.3 ns\n      <\/td>\n\n        107.093 ns\n      <\/td>\n\n        105.180 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        LoopLongs\n      <\/td>\n\n        568.6 ns\n      <\/td>\n\n        6.895 ns\n      <\/td>\n\n        5.758 ns\n      <\/td>\n\n        0.10\n      <\/td>\n<\/tr>\n
        \n        LoopVectors\n      <\/td>\n\n        306.0 ns\n      <\/td>\n\n        4.502 ns\n      <\/td>\n\n        4.211 ns\n      <\/td>\n\n        0.06\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Further, .NET Core 3.0 includes new hardware intrinsics that allow a properly-motivated developer to eke out the best possible performance on supporting hardware, utilizing extensions like AVX or SSE that can compare well more than 8 bytes at a time. Many of the improvements in .NET Core 3.0 come from utilizing these techniques. Back to examples, copying spans has also improved, thanks to PRs\u00a0<\/p>\n
        dotnet\/coreclr#18006<\/a>\u00a0from @benaadams and\u00a0dotnet\/coreclr#17889<\/a>, in particular for relatively small spans…<\/p>\n
        private byte[] _from = new byte[] { 1, 2, 3, 4 };\nprivate byte[] _to = new byte[4];\n\n[Benchmark]\npublic void CopySpan() => _from.AsSpan().CopyTo(_to);<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        CopySpan\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        10.913 ns\n      <\/td>\n\n        0.1960 ns\n      <\/td>\n\n        0.1737 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        CopySpan\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        3.568 ns\n      <\/td>\n\n        0.0528 ns\n      <\/td>\n\n        0.0494 ns\n      <\/td>\n\n        0.33\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Searching is one of the most commonly performed operations in any program, and searches with spans are generally performed with\u00a0<\/p>\n
        IndexOf<\/code>\u00a0and its variants (e.g.\u00a0IndexOfAny<\/code>\u00a0and\u00a0Contains<\/code>) In PR\u00a0dotnet\/coreclr#20738<\/a>, @benaadams again utilized vectorization, this time to improve the performance of\u00a0IndexOfAny<\/code>\u00a0when operating over bytes, a particularly common case in many networking-related scenarios (e.g. parsing bytes off the wire as part of an HTTP stack). You can see the effects of this in the following microbenchmark:<\/p>\n
        private byte[] _arr = Encoding.UTF8.GetBytes(\"This is a test to see improvements to IndexOfAny.  How'd they work?\");\n[Benchmark] public int IndexOf() => new Span<byte>(_arr).IndexOfAny((byte)'.', (byte)'?');<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        12.828 ns\n      <\/td>\n\n        0.1805 ns\n      <\/td>\n\n        0.1600 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        4.504 ns\n      <\/td>\n\n        0.0968 ns\n      <\/td>\n\n        0.0858 ns\n      <\/td>\n\n        0.35\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 I love these kinds of improvements, because they’re low-enough in the stack that they end up having multiplicative effects across so much code. The above change only affected\u00a0<\/p>\n
        byte<\/code>, but subsequent PRs were submitted to cover\u00a0char<\/code>\u00a0as well, and then PR\u00a0dotnet\/coreclr#20855<\/a>\u00a0made a nice change that brought these same changes to other primitives of the same sizes. For example, we can recast the previous benchmark to use sbyte instead of byte, and as of that PR, a similar improvement applies:<\/p>\n
        private sbyte[] _arr = Encoding.UTF8.GetBytes(\"This is a test to see improvements to IndexOfAny.  How'd they work?\").Select(b => (sbyte)b).ToArray();\n\n[Benchmark]\npublic int IndexOf() => new Span<sbyte>(_arr).IndexOfAny((sbyte)'.', (sbyte)'?');<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        24.636 ns\n      <\/td>\n\n        0.2292 ns\n      <\/td>\n\n        0.2144 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        9.795 ns\n      <\/td>\n\n        0.1419 ns\n      <\/td>\n\n        0.1258 ns\n      <\/td>\n\n        0.40\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 As another example, consider PR\u00a0<\/p>\n
        dotnet\/coreclr#20275<\/a>. That change similarly utilized vectorization to improve the performance of To{Upper\/Lower}{Invariant}.<\/p>\n
        private string _src = \"This is a source string that needs to be capitalized.\";\nprivate char[] _dst = new char[1024];\n[Benchmark] public int ToUpperInvariant() => _src.AsSpan().ToUpperInvariant(_dst);<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        ToUpperInvariant\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        64.36 ns\n      <\/td>\n\n        0.8099 ns\n      <\/td>\n\n        0.6763 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        ToUpperInvariant\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        26.48 ns\n      <\/td>\n\n        0.2411 ns\n      <\/td>\n\n        0.2137 ns\n      <\/td>\n\n        0.41\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 PR\u00a0<\/p>\n
        dotnet\/coreclr#19959<\/a>\u00a0optimizes the Trim{Start\/End} helpers on\u00a0ReadOnlySpan<char><\/code>, another very commonly-applied method, with equally exciting results (it’s hard to see with the white space in the results, but the results in the table go in order of the arguments in the Params attribute):<\/p>\n
        [Params(\"\", \" abcdefg \", \"abcdefg\")]\npublic string Data;\n\n[Benchmark]\npublic ReadOnlySpan<char> Trim() => Data.AsSpan().Trim();<\/pre>\n\n\n\n\n\n\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Data\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        Trim\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n      <\/td>\n\n        12.999 ns\n      <\/td>\n\n        0.1913 ns\n      <\/td>\n\n        0.1789 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        Trim\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n      <\/td>\n\n        3.078 ns\n      <\/td>\n\n        0.0349 ns\n      <\/td>\n\n        0.0326 ns\n      <\/td>\n\n        0.24\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        Trim\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        abcdefg\n      <\/td>\n\n        17.618 ns\n      <\/td>\n\n        0.3534 ns\n      <\/td>\n\n        0.2951 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        Trim\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        abcdefg\n      <\/td>\n\n        7.927 ns\n      <\/td>\n\n        0.0934 ns\n      <\/td>\n\n        0.0828 ns\n      <\/td>\n\n        0.45\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        Trim\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        abcdefg\n      <\/td>\n\n        15.522 ns\n      <\/td>\n\n        0.2200 ns\n      <\/td>\n\n        0.1951 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        Trim\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        abcdefg\n      <\/td>\n\n        5.227 ns\n      <\/td>\n\n        0.0750 ns\n      <\/td>\n\n        0.0665 ns\n      <\/td>\n\n        0.34\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Sometimes optimizations are just about being smarter about code management. PR\u00a0<\/p>\n
        dotnet\/coreclr#17890<\/a>\u00a0removed an unnecessary layer of functions that were on many globalization-related code paths, and just removing those extra unnecessary method invocations results in measurable speed-ups when working with small spans, e.g.<\/p>\n
        \n
        [Benchmark]\npublic bool EndsWith() => \"Hello world\".AsSpan().EndsWith(\"world\", StringComparison.OrdinalIgnoreCase);<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        EndsWith\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        37.80 ns\n      <\/td>\n\n        0.3290 ns\n      <\/td>\n\n        0.2917 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        EndsWith\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        12.26 ns\n      <\/td>\n\n        0.1479 ns\n      <\/td>\n\n        0.1384 ns\n      <\/td>\n\n        0.32\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Of course, one of the great things about span is that it is a reusable building-block that enables many higher-level operations. That includes operations on both arrays and strings…<\/p>\n
        Arrays and Strings<\/h3>\n
        As a theme that’s emerged within .NET Core, wherever possible, new performance-focused functionality should not only be exposed for public use but also be used internally; after all, given the depth and breadth of functionality within .NET Core, if some performance-focused feature doesn’t meet the needs of .NET Core itself, there’s a reasonable chance it also won’t meet the public need. As such, internal usage of new features is a key benchmark as to whether the design is adequate, and in the process of evaluating such criteria, many additional code paths benefit, and these improvements have a multiplicative effect. This isn’t just about new APIs. Many of the language features introduced in C# 7.2, 7.3, and 8.0 are influenced by the needs of .NET Core itself and have been used to improve things that we couldn’t reasonably improve before (other than dropping down to unsafe code, which we try to avoid when possible). For example, PR\u00a0dotnet\/coreclr#17891<\/a>\u00a0speeds up Array.Reverse by taking advantage of the C# 7.2 ref locals feature and the 7.3 ref local reassignment feature. Using the new feature allows for the code to be expressed in a way that lets the JIT generate better code for the inner loop, and in turn results in a measurable speed-up:<\/p>\n
        private int[] _arr = Enumerable.Range(0, 256).ToArray();\n\n[Benchmark]\npublic void Reverse() => Array.Reverse(_arr);<\/pre>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        RatioSD\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        Reverse\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        105.06 ns\n      <\/td>\n\n        2.488 ns\n      <\/td>\n\n        7.337 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        Reverse\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        74.12 ns\n      <\/td>\n\n        1.494 ns\n      <\/td>\n\n        2.536 ns\n      <\/td>\n\n        0.66\n      <\/td>\n\n        0.02\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Another example for arrays, the\u00a0<\/p>\n
        Clear<\/code>\u00a0method improved in PR\u00a0dotnet\/coreclr#24302<\/a>, which works around an alignment issue that results in the underlying memset used to implement the operation being up to 2x slower. The change manually clears up to a few bytes one by one, such that the pointer we then hand off to memset is properly aligned. If you got “lucky” previously and the array happened to be aligned, performance was fine, but if it wasn’t aligned, there was a non-trivial performance hit incurred. This benchmark simulates the unlucky case:<\/p>\n
        \n
        [GlobalSetup]\npublic void Setup()\n{\n    while (true)\n    {\n        var buffer = new byte[8192];\n        GCHandle handle = GCHandle.Alloc(buffer, GCHandleType.Pinned);\n        if (((long)handle.AddrOfPinnedObject()) % 32 != 0)\n        {\n            _handle = handle;\n            _buffer = buffer;\n            return;\n        }\n        handle.Free();\n    }\n}\n\n[GlobalCleanup]\npublic void Cleanup() => _handle.Free();\n\nprivate GCHandle _handle;\nprivate byte[] _buffer;\n\n[Benchmark] public void Clear() => Array.Clear(_buffer, 0, _buffer.Length);<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        Clear\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        121.59 ns\n      <\/td>\n\n        0.8349 ns\n      <\/td>\n\n        0.6519 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        Clear\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        87.91 ns\n      <\/td>\n\n        1.7768 ns\n      <\/td>\n\n        1.6620 ns\n      <\/td>\n\n        0.73\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 That said, many of the improvements are in fact based on new APIs. Span is a great example of this. It was introduced in .NET Core 2.1, and the initial push was to get it to be usable and expose sufficient surface area to allow it to be used meaningfully. But at the same time, we started utilizing it internally in order to both vet the design and benefit from the improvements it enables. Some of this was done in .NET Core 2.1, but the effort continues in .NET Core 3.0. Arrays and strings are both prime candidates for such optimizations. For example, many of the same vectorization optimizations applied to spans are similarly applied to arrays. PR\u00a0<\/p>\n
        dotnet\/coreclr#21116<\/a>\u00a0from @benaadams optimized\u00a0Array.{Last}IndexOf<\/code>\u00a0for both\u00a0byte<\/code>s and\u00a0char<\/code>s, utilizing the same internal helpers that were written to enable spans, and to similar effect:<\/p>\n
        \n
        private char[] _arr = \"This is a test to see improvements to IndexOf.  How'd they work?\".ToCharArray();\n\n[Benchmark]\npublic int IndexOf() => Array.IndexOf(_arr, '.');<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        RatioSD\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        34.976 ns\n      <\/td>\n\n        0.6352 ns\n      <\/td>\n\n        0.5631 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        9.471 ns\n      <\/td>\n\n        0.6638 ns\n      <\/td>\n\n        1.1091 ns\n      <\/td>\n\n        0.29\n      <\/td>\n\n        0.04\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 And as with spans, thanks to PR\u00a0<\/p>\n
        dotnet\/coreclr#24293<\/a>\u00a0from @dschinde, these\u00a0IndexOf<\/code>optimizations also now apply to other primitives of the same size.<\/p>\n
        \n
        private short[] _arr = \"This is a test to see improvements to IndexOf.  How'd they work?\".Select(c => (short)c).ToArray();\n\n[Benchmark]\npublic int IndexOf() => Array.IndexOf(_arr, (short)'.');<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        34.181 ns\n      <\/td>\n\n        0.6626 ns\n      <\/td>\n\n        0.6508 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        9.600 ns\n      <\/td>\n\n        0.1913 ns\n      <\/td>\n\n        0.1598 ns\n      <\/td>\n\n        0.28\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Vectorization optimizations have been applied to strings, too. You can see the effect of PR\u00a0<\/p>\n
        dotnet\/coreclr#21076<\/a>\u00a0from @benaadams in this microbenchmark:<\/p>\n
        \n
        [Benchmark]\npublic int IndexOf() => \"Let's see how fast we can find the period towards the end of this string.  Pretty fast?\".IndexOf('.', StringComparison.Ordinal);<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        Gen 0\n      <\/th>\n\n        Gen 1\n      <\/th>\n\n        Gen 2\n      <\/th>\n\n        Allocated\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        75.14 ns\n      <\/td>\n\n        1.5285 ns\n      <\/td>\n\n        1.6355 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.0151\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n\n        32 B\n      <\/td>\n<\/tr>\n
        \n        IndexOf\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        11.70 ns\n      <\/td>\n\n        0.2382 ns\n      <\/td>\n\n        0.2111 ns\n      <\/td>\n\n        0.16\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Also note in the above that the .NET Core 2.1 operation allocates (due to converting the search character into a string), whereas the .NET Core 3.0 implementation does not. That’s thanks to PR\u00a0<\/p>\n
        dotnet\/coreclr#19788<\/a> from @benaadams. There are of course pieces of functionality that are more unique to strings (albeit also applicable to new functionality exposed on spans), such as hash code computation with various string comparison methods. For example, PR\u00a0dotnet\/coreclr#20309\/<\/a>\u00a0improved the performance of\u00a0String.GetHashCode<\/code>\u00a0when performing\u00a0OrdinalIgnoreCase<\/code>\u00a0operations, which along with\u00a0Ordinal<\/code>\u00a0(the default) represent the two most common modes.<\/p>\n
        \n
        [Benchmark]\npublic int GetHashCodeIgnoreCase() => \"Some string\".GetHashCode(StringComparison.OrdinalIgnoreCase);<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        GetHashCodeIgnoreCase\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        47.70 ns\n      <\/td>\n\n        0.5751 ns\n      <\/td>\n\n        0.5380 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        GetHashCodeIgnoreCase\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        14.28 ns\n      <\/td>\n\n        0.1462 ns\n      <\/td>\n\n        0.1296 ns\n      <\/td>\n\n        0.30\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0<\/p>\n
        OrdinalsIgnoreCase<\/code>\u00a0has been improved for other uses as well. For example, PR\u00a0dotnet\/coreclr#20734<\/a>\u00a0improved\u00a0String.Equals<\/code>\u00a0when using\u00a0StringComparer.OrdinalIgnoreCase<\/code>by both vectorizing (checking two chars at a time instead of one) and removing branches from an inner loop:<\/p>\n
        \n
        [Benchmark]\npublic bool EqualsIC() => \"Some string\".Equals(\"sOME sTrinG\", StringComparison.OrdinalIgnoreCase);<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        EqualsIC\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        24.036 ns\n      <\/td>\n\n        0.3819 ns\n      <\/td>\n\n        0.3572 ns\n      <\/td>\n\n        1.00\n      <\/td>\n<\/tr>\n
        \n        EqualsIC\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        9.165 ns\n      <\/td>\n\n        0.0589 ns\n      <\/td>\n\n        0.0551 ns\n      <\/td>\n\n        0.38\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 The previous cases are examples of functionality in\u00a0<\/p>\n
        String<\/code>‘s implementation, but there are lots of ancillary string-related functionality that have seen improvements as well. For example, various operations on\u00a0Char<\/code>\u00a0have been improved, such as\u00a0Char.GetUnicodeCategory<\/code>\u00a0via PRs\u00a0dotnet\/coreclr#20983<\/a>\u00a0and\u00a0dotnet\/coreclr#20864<\/a>:<\/p>\n
        \n
        [Params('.', 'a', '\\x05D0')]\npublic char Char { get; set; }\n\n[Benchmark]\npublic UnicodeCategory GetCategory() => char.GetUnicodeCategory(Char);<\/pre>\n<\/div>\n\n\n\n\n\n\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Char\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        RatioSD\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        GetCategory\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        .\n      <\/td>\n\n        1.8001 ns\n      <\/td>\n\n        0.0160 ns\n      <\/td>\n\n        0.0142 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        GetCategory\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        .\n      <\/td>\n\n        0.4925 ns\n      <\/td>\n\n        0.0141 ns\n      <\/td>\n\n        0.0132 ns\n      <\/td>\n\n        0.27\n      <\/td>\n\n        0.01\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        GetCategory\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        a\n      <\/td>\n\n        1.7925 ns\n      <\/td>\n\n        0.0144 ns\n      <\/td>\n\n        0.0127 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        GetCategory\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        a\n      <\/td>\n\n        0.4957 ns\n      <\/td>\n\n        0.0117 ns\n      <\/td>\n\n        0.0091 ns\n      <\/td>\n\n        0.28\n      <\/td>\n\n        0.01\n      <\/td>\n<\/tr>\n
        \n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n\n      <\/td>\n<\/tr>\n
        \n        GetCategory\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        ?\n      <\/td>\n\n        3.7836 ns\n      <\/td>\n\n        0.0493 ns\n      <\/td>\n\n        0.0461 ns\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n<\/tr>\n
        \n        GetCategory\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        ?\n      <\/td>\n\n        2.7531 ns\n      <\/td>\n\n        0.0757 ns\n      <\/td>\n\n        0.0633 ns\n      <\/td>\n\n        0.73\n      <\/td>\n\n        0.02\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Those PRs also highlight another case of benefiting from a language improvement. As of C# 7.3, the C# compiler is able to optimize properties of the form:<\/p>\n
        \n
        static ReadOnlySpan<byte> s_byteData => new byte[] { \u2026 \/* constant bytes *\/ }<\/pre>\n
          Rather than emitting this exactly as written, which would allocate a new byte array on each call, the compiler takes advantage of the facts that a) the bytes backing the array are all constant and b) it’s being returned as a read-only span, which means the consumer is unable to mutate the data using safe code. As such, with PR\u00a0<\/span>dotnet\/roslyn#24621<\/a>, the C# compiler instead emits this by writing the bytes as a binary blob in metadata, and the property then simply creates a span that points directly to that data, making it very fast to access the data, more so even than if this property returned a static byte[].<\/span>\n<\/div>\n
        \n
        \/\/ Run with: dotnet run -c Release -f netcoreapp2.1 --filter *Program* --runtimes netcoreapp3.0\n\nprivate static byte[] ArrayProp { get; } = new byte[] { 1, 2, 3 };\n\n[Benchmark(Baseline = true)]\npublic ReadOnlySpan<byte> GetArrayProp() => ArrayProp;\n\nprivate static ReadOnlySpan<byte> SpanProp => new byte[] { 1, 2, 3 };\n\n[Benchmark]\npublic ReadOnlySpan<byte> GetSpanProp() => SpanProp;<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Median\n      <\/th>\n\n        Ratio\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        GetArrayProp\n      <\/td>\n\n        1.3362 ns\n      <\/td>\n\n        0.0498 ns\n      <\/td>\n\n        0.0416 ns\n      <\/td>\n\n        1.3366 ns\n      <\/td>\n\n        1.000\n      <\/td>\n<\/tr>\n
        \n        GetSpanProp\n      <\/td>\n\n        0.0125 ns\n      <\/td>\n\n        0.0132 ns\n      <\/td>\n\n        0.0110 ns\n      <\/td>\n\n        0.0080 ns\n      <\/td>\n\n        0.009\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0 Another string-related area that’s gotten some attention is\u00a0<\/p>\n
        StringBuilder<\/code>\u00a0(not necessarily improvements to\u00a0StringBuilder<\/code>\u00a0itself, although it has received some of those, for example a new overload in PR\u00a0dotnet\/coreclr#20773<\/a>\u00a0from @Wraith2 that helps avoid accidentally boxing and creating a string from a\u00a0ReadOnlyMemory<char><\/code>\u00a0appended to the builder). Rather, in many situations\u00a0StringBuilder<\/code>s have been used for convenience but added cost, and with just a little work (and in some cases the new\u00a0String.Create<\/code>\u00a0method introduced in .NET Core 2.1), we can eliminate that overhead, in both CPU usage and allocation. Here a few examples\u2026 * PR\u00a0dotnet\/corefx#33598<\/a>\u00a0removed a\u00a0StringBuilder<\/code>\u00a0used in marshaling from\u00a0Dns.GetHostEntry<\/code>:<\/p>\n
        \n
        [Benchmark]\npublic IPHostEntry GetHostEntry() => Dns.GetHostEntry(\"34.206.253.53\");<\/pre>\n<\/div>\n\n\n\n\n\n\n
        \n        Method\n      <\/th>\n\n        Toolchain\n      <\/th>\n\n        Mean\n      <\/th>\n\n        Error\n      <\/th>\n\n        StdDev\n      <\/th>\n\n        Median\n      <\/th>\n\n        Ratio\n      <\/th>\n\n        RatioSD\n      <\/th>\n\n        Gen 0\n      <\/th>\n\n        Gen 1\n      <\/th>\n\n        Gen 2\n      <\/th>\n\n        Allocated\n      <\/th>\n<\/tr>\n<\/thead>\n
        \n        GetHostEntry\n      <\/td>\n\n        netcoreapp2.1\n      <\/td>\n\n        532.7 us\n      <\/td>\n\n        16.59 us\n      <\/td>\n\n        46.79 us\n      <\/td>\n\n        526.8 us\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.00\n      <\/td>\n\n        1.9531\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n\n        4888 B\n      <\/td>\n<\/tr>\n
        \n        GetHostEntry\n      <\/td>\n\n        netcoreapp3.0\n      <\/td>\n\n        527.7 us\n      <\/td>\n\n        12.85 us\n      <\/td>\n\n        37.06 us\n      <\/td>\n\n        542.8 us\n      <\/td>\n\n        1.00\n      <\/td>\n\n        0.11\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n\n        –\n      <\/td>\n\n        616 B\n      <\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        \u00a0<\/p>\n