冯辉

【翻译】.NET 5中的性能改进

在.NET Core之前的版本中，其实已经在博客中介绍了在该版本中发现的重大性能改进。从.NET Core 2.0到.NET Core 2.1到.NET Core 3.0的每一篇文章，发现
谈论越来越多的东西。然而有趣的是，每次都想知道下一次是否有足够的意义的改进以保证再发表一篇文章。 .NET 5已经实现了许多性能改进，尽管直到今年秋天才计划发布最终版本，并且到那时很有可能会有更多的改进，但是还要强调一下，现在已提供的改进。在这篇文章中，重点介绍约250个PR，这些请求为整个.NET 5的性能提升做出了巨大贡献。

安装

Benchmark.NET现在是衡量.NET代码性能的规范工具，可轻松分析代码段的吞吐量和分配。因此，本文中大部分示例都是使用使用该工具编写的微基准来衡量的。首先创建了一个目录，然后使用dotnet工具对其进行了扩展：

mkdir Benchmarks
cd Benchmarks
dotnet new console

生成的Benchmarks.csproj的内容扩展为如下所示：



  
    Exe
    true
    true
    net5.0;netcoreapp3.1;net48

这样，就可以针对.NET Framework 4.8，.NET Core 3.1和.NET 5执行基准测试（目前已为Preview 8安装了每晚生成的版本）。.csproj还引用Benchmark.NET NuGet软件包（其最新版本为12.1版），以便能够使用其功能，然后引用其他几个库和软件包，特别是为了支持能够在其上运行测试 .NET Framework 4.8。
然后，将生成的Program.cs文件更新到同一文件夹中，如下所示：

using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Diagnosers;
using BenchmarkDotNet.Running;
using System;
using System.Buffers.Text;
using System.Collections;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Collections.Immutable;
using System.IO;
using System.Linq;
using System.Net;
using System.Net.Http;
using System.Net.Security;
using System.Net.Sockets;
using System.Runtime.CompilerServices;
using System.Threading;
using System.Threading.Tasks;
using System.Text;
using System.Text.Json;
using System.Text.RegularExpressions;

[MemoryDiagnoser]
public class Program
{
    static void Main(string[] args) => BenchmarkSwitcher.FromAssemblies(new[] { typeof(Program).Assembly }).Run(args);

    // BENCHMARKS GO HERE
}

对于每次测试，每个示例中显示的基准代码复制/粘贴将显示"// BENCHMARKS GO HERE"的位置。
为了运行基准测试，然后做：

dotnet run -c Release -f net48 --runtimes net48 netcoreapp31 netcoreapp50 --filter ** --join

这告诉Benchmark.NET：

使用.NET Framework 4.8 来建立基准。
针对.NET Framework 4.8，.NET Core 3.1和.NET 5分别运行基准测试。
在程序集中包含所有基准测试（不要过滤掉任何基准测试）。
将所有基准测试的输出结果合并在一起，并在运行结束时显示（而不是贯穿整个过程）。

在某些情况下，针对特定目标的API并不存在，我只是省略了命令行的这一部分。

最后，请注意以下几点：

从运行时和核心库的角度来看，它与几个月前发布的前身相比没有多少改进。但是，还进行了一些改进，在某些情况下，目前已经将.NET 5的改进移植回了.NET Core 3.1，在这些改进中，这些更改被认为具有足够的影响力，可以保证可以添加到长期支持中（LTS）版本。因此，我在这里所做的所有比较都是针对最新的.NET Core 3.1服务版本（3.1.5），而不是针对.NET Core 3.0。
由于比较是关于.NET 5与.NET Core 3.1的，而且.NET Core 3.1不包括mono运行时，因此不讨论对mono所做的改进，也没有专门针对“Blazor”。因此，当指的是“runtime”时，指的是coreclr，即使从.NET 5开始，它也包含多个运行时，并且所有这些都已得到改进。
大多数示例都在Windows上运行，因为也希望能够与.NET Framework 4.8进行比较。但是，除非另有说明，否则所有显示的示例均适用于Windows，Linux和macOS。
需要注意的是: 这里的所有测量数据都是在的台式机上进行的，测量结果可能会有所不同。微基准测试对许多因素都非常敏感，包括处理器数量、处理器架构、内存和缓存速度等等。但是，一般来说，我关注的是性能改进，并包含了通常能够承受此类差异的示例。

让我们开始吧…

GC

对于所有对.NET和性能感兴趣的人来说，垃圾收集通常是他们最关心的。在减少分配上花费了大量的精力，不是因为分配行为本身特别昂贵，而是因为通过垃圾收集器(GC)清理这些分配之后的后续成本。然而，无论减少分配需要做多少工作，绝大多数工作负载都会导致这种情况发生，因此，重要的是要不断提高GC能够完成的任务和速度。

这个版本在改进GC方面做了很多工作。例如， dotnet/coreclr#25986 为GC的“mark”阶段实现了一种形式的工作窃取。.NET GC是一个“tracing”收集器，这意味着(在非常高的级别上)当它运行时，它从一组“roots”(已知的固有可访问的位置，比如静态字段)开始，从一个对象遍历到另一个对象，将每个对象“mark”为可访问;在所有这些遍历之后，任何没有标记的对象都是不可访问的，可以收集。此标记代表了执行集合所花费的大部分时间，并且此PR通过更好地平衡集合中涉及的每个线程执行的工作来改进标记性能。当使用“Server GC”运行时，每个核都有一个线程参与收集，当线程完成分配给它们的标记工作时，它们现在能够从其他线程“steal” 未完成的工作，以帮助更快地完成整个收集。

另一个例子是，dotnet/runtime#35896 “ephemeral”段的解压进行了优化(gen0和gen1被称为 “ephemeral”，因为它们是预期只持续很短时间的对象)。在段的最后一个活动对象之后，将内存页返回给操作系统。那么GC的问题就变成了，这种解解应该在什么时候发生，以及在任何时候应该解解多少，因为在不久的将来，它可能需要为额外的分配分配额外的页面。

或者以dotnet/runtime#32795,为例，它通过减少在GC静态扫描中涉及的锁争用，提高了在具有较高核心计数的机器上的GC可伸缩性。或者dotnet/runtime#37894，它避免了代价高昂的内存重置(本质上是告诉操作系统相关的内存不再感兴趣)，除非GC看到它处于低内存的情况。或者dotnet/runtime#37159，它(虽然还没有合并，预计将用于.NET5 )构建在@damageboy的工作之上，用于向量化GC中使用的排序。或者 dotnet/coreclr#27729，它减少了GC挂起线程所花费的时间，这对于它获得一个稳定的视图，从而准确地确定正在使用的线程是必要的。

这只是改进GC本身所做的部分更改，但最后一点给我带来了一个特别吸引我的话题，因为它涉及到近年来我们在.NET中所做的许多工作。在这个版本中，我们继续，甚至加快了从C/C++移植coreclr运行时中的本地实现，以取代System.Private.Corelib中的普通c#托管代码。此举有大量的好处,包括让我们更容易共享一个实现跨多个运行时(如coreclr和mono),甚至对我们来说更容易进化API表面积,如通过重用相同的逻辑来处理数组和跨越。但让一些人吃惊的是，这些好处还包括多方面的性能。其中一种方法回溯到使用托管运行时的最初动机:安全性。默认情况下，用c#编写的代码是“safe”，因为运行时确保所有内存访问都检查了边界，只有通过代码中可见的显式操作(例如使用unsafe关键字，Marshal类，unsafe类等)，开发者才能删除这种验证。结果,作为一个开源项目的维护人员,我们的工作的航运安全系统在很大程度上使当贡献托管代码的形式:虽然这样的代码可以当然包含错误,可能会通过代码审查和自动化测试,我们可以晚上睡得更好知道这些bug引入安全问题的几率大大降低。这反过来意味着我们更有可能接受托管代码的改进，并且速度更快，贡献者提供的更快，我们帮助验证的更快。我们还发现，当使用c#而不是C时，有更多的贡献者对探索性能改进感兴趣，而且更多的人以更快的速度进行实验，从而获得更好的性能。

然而，我们从移植中看到了更直接的性能改进。托管代码调用运行时所需的开销相对较小，但是如果调用频率很高，那么开销就会增加。考虑dotnet/coreclr#27700，它将原始类型数组排序的实现从coreclr的本地代码移到了Corelib的c#中。除了这些代码之外，它还为新的公共api提供了对跨度进行排序的支持，它还降低了对较小数组进行排序的成本，因为排序的成本主要来自于从托管代码的转换。我们可以在一个小的基准测试中看到这一点，它只是使用数组。对包含10个元素的int[]， double[]和string[]数组进行排序:

public class DoubleSorting : Sorting { protected override double GetNext() => _random.Next(); }
public class Int32Sorting : Sorting { protected override int GetNext() => _random.Next(); }
public class StringSorting : Sorting
{
    protected override string GetNext()
    {
        var dest = new char[_random.Next(1, 5)];
        for (int i = 0; i < dest.Length; i++) dest[i] = (char)('a' + _random.Next(26));
        return new string(dest);
    }
}

public abstract class Sorting
{
    protected Random _random;
    private T[] _orig, _array;

    [Params(10)]
    public int Size { get; set; }

    protected abstract T GetNext();

    [GlobalSetup]
    public void Setup()
    {
        _random = new Random(42);
        _orig = Enumerable.Range(0, Size).Select(_ => GetNext()).ToArray();
        _array = (T[])_orig.Clone();
        Array.Sort(_array);
    }

    [Benchmark]
    public void Random()
    {
        _orig.AsSpan().CopyTo(_array);
        Array.Sort(_array);
    }
}

Type	Runtime	Mean	Ratio
DoubleSorting	.NET FW 4.8	88.88 ns	1.00
DoubleSorting	.NET Core 3.1	73.29 ns	0.83
DoubleSorting	.NET 5.0	35.83 ns	0.40

Int32Sorting	.NET FW 4.8	66.34 ns	1.00
Int32Sorting	.NET Core 3.1	48.47 ns	0.73
Int32Sorting	.NET 5.0	31.07 ns	0.47

StringSorting	.NET FW 4.8	2,193.86 ns	1.00
StringSorting	.NET Core 3.1	1,713.11 ns	0.78
StringSorting	.NET 5.0	1,400.96 ns	0.64

这本身就是这次迁移的一个很好的好处，因为我们在.NET5中通过dotnet/runtime#37630 添加了System.Half，一个新的原始16位浮点，并且在托管代码中，这个排序实现的优化几乎立即应用到它，而以前的本地实现需要大量的额外工作，因为没有c++标准类型的一半。但是，这里还有一个更有影响的性能优势，这让我们回到我开始讨论的地方:GC。

GC的一个有趣指标是“pause time”，这实际上意味着GC必须暂停运行时多长时间才能执行其工作。更长的暂停时间对延迟有直接的影响，而延迟是所有工作负载方式的关键指标。正如前面提到的,GC可能需要暂停线程为了得到一个一致的世界观,并确保它能安全地移动对象,但是如果一个线程正在执行C/c++代码在运行时,GC可能需要等到调用完成之前暂停的线程。因此，我们在托管代码而不是本机代码中做的工作越多，GC暂停时间就越好。我们可以使用相同的数组。排序的例子，看看这个。考虑一下这个程序:

using System;
using System.Diagnostics;
using System.Threading;

class Program
{
    public static void Main()
    {
        new Thread(() =>
        {
            var a = new int[20];
            while (true) Array.Sort(a);
        }) { IsBackground = true }.Start();

        var sw = new Stopwatch();
        while (true)
        {
            sw.Restart();
            for (int i = 0; i < 10; i++)
            {
                GC.Collect();
                Thread.Sleep(15);
            }
            Console.WriteLine(sw.Elapsed.TotalSeconds);
        }
    }
}

这是让一个线程在一个紧密循环中不断地对一个小数组排序，而在主线程上，它执行10次GCs，每次GCs之间大约有15毫秒。我们预计这个循环会花费150毫秒多一点的时间。但当我在.NET Core 3.1上运行时，我得到的秒数是这样的

在这里，GC很难中断执行排序的线程，导致GC暂停时间远远高于预期。幸运的是，当我在 .NET5 上运行这个时，我得到了这样的数字:

这正是我们预测的结果。通过移动数组。将实现排序到托管代码中，这样运行时就可以在需要时更容易地挂起实现，我们使GC能够更好地完成其工作。

当然，这不仅限于Array.Sort。一堆PR进行了这样的移植，例如dotnet/runtime#32722将stdelemref和ldelemaref JIT helper 移动到C＃，dotnet/runtime#32353 将unbox helpers的一部分移动到C＃（并使用适当的GC轮询位置来检测其余部分） GC在其余位置适当地暂停），dotnet/coreclr#27603 / dotnet/coreclr#27634 / dotnet/coreclr#27123 / dotnet/coreclr#27776 移动更多的数组实现，如Array.Clear和Array.Copy到C＃， dotnet/coreclr#27216 将更多Buffer移至C＃，而dotnet/coreclr#27792将Enum.CompareTo移至C＃。这些更改中的一些然后启用了后续增益，例如 dotnet/runtime#32342和dotnet/runtime#35733，它们利用Buffer.Memmove的改进来在各种字符串和数组方法中获得额外的收益。

关于这组更改的最后一个想法是，需要注意的另一件有趣的事情是，在一个版本中所做的微优化是如何基于后来被证明无效的假设的，并且当使用这种微优化时，需要准备并愿意适应。在我的.NET Core 3.0博客中，我提到了像dotnet/coreclr#21756这样的“peanut butter”式的改变，它改变了很多使用数组的调用站点。复制(源，目标，长度)，而不是使用数组。复制(source, sourceOffset, destination, destinationOffset, length)，因为前者获取源数组和目标数组的下限的开销是可测量的。但是通过前面提到的将数组处理代码移动到c#的一系列更改，更简单的重载的开销消失了，使其成为这些操作更简单、更快的选择。这样，.NET5 PRs dotnet/coreclr#27641和dotnet/corefx#42343切换了所有这些呼叫站点，更多地回到使用更简单的过载。dotnet/runtime#36304是另一个取消之前优化的例子，因为更改使它们过时或实际上有害。你总是能够传递一个字符到字符串。分裂,如version.Split (' . ')。然而，问题是，这个绑定到Split的唯一重载是Split(params char[] separator)，这意味着每次这样的调用都会导致c#编译器生成一个char[]分配。为了解决这个问题，以前的版本添加了缓存，提前分配数组并将它们存储到静态中，然后可以被分割调用使用，以避免每个调用都使用char[]。既然.NET中有一个Split(char separator, StringSplitOptions options = StringSplitOptions. none)重载，我们就不再需要数组了。
作为最后一个示例，我展示了将代码移出运行时并转移到托管代码中如何帮助GC暂停，但是当然还有其他方式可以使运行时中剩余的代码对此有所帮助。dotnet/runtime#36179通过确保运行时处于代码争抢模式下（例如获取“Watson”存储桶参数（基本上是一组用于唯一标识此特定异常和调用堆栈以用于报告目的的数据）），从而减少了由于异常处理而导致的GC暂停。。暂停。

JIT

.NET5 也是即时(JIT)编译器的一个令人兴奋的版本，该版本中包含了各种各样的改进。与任何编译器一样，对JIT的改进可以产生广泛的影响。通常，单独的更改对单独的代码段的影响很小，但是这样的更改会被它们应用的地方的数量放大。
可以向JIT添加的优化的数量几乎是无限的，如果给JIT无限的时间来运行这种优化，JIT就可以为任何给定的场景创建最优代码。但是JIT的时间并不是无限的。JIT的“即时”特性意味着它在应用程序运行时执行编译:当调用尚未编译的方法时，JIT需要按需为其提供汇编代码。这意味着在编译完成之前线程不能向前推进，这反过来意味着JIT需要在应用什么优化以及如何选择使用有限的时间预算方面有策略。各种技术用于给JIT更多的时间,比如使用“提前”(AOT)编译应用程序的一些部分做尽可能多的编译工作前尽可能执行应用程序(例如,AOT编译核心库都使用一个叫“ReadyToRun”的技术,你可能会听到称为“R2R”甚至“crossgen”,是产生这些图像的工具),或使用“tiered compilation”,它允许JIT在最初编译一个应用了从少到少优化的方法，因此速度非常快，只有在它被认为有价值的时候(即该方法被重复使用的时候)，才会花更多的时间使用更多优化来重新编译它。然而，更普遍的情况是，参与JIT的开发人员只是选择使用分配的时间预算进行优化，根据开发人员编写的代码和他们使用的代码模式，这些优化被证明是有价值的。这意味着，随着.NET的发展并获得新的功能、新的语言特性和新的库特性，JIT也会随着适合于编写的较新的代码风格的优化而发展。
一个很好的例子是@benaadams的dotnet/runtime#32538。 Span 一直渗透到.NET堆栈的所有层，因为从事运行时，核心库，ASP.NET Core的开发人员以及其他人在编写安全有效的代码（也统一了字符串处理）时认识到了它的强大功能，托管数组，本机分配的内存和其他形式的数据。类似地，值类型（结构）被越来越普遍地用作通过堆栈分配避免对象分配开销的一种方式。但是，对此类类型的严重依赖也给运行时带来了更多麻烦。 coreclr运行时使用“precise” garbage collector，这意味着GC能够100％准确地跟踪哪些值引用托管对象，哪些值不引用托管对象；这样做有好处，但也有代价（相反，mono运行时使用“conservative”垃圾收集器，这具有一些性能上的好处，但也意味着它可以解释堆栈上的任意值，而该值恰好与被管理对象的地址作为对该对象的实时引用）。这样的代价之一是，JIT需要通过确保在GC注意之前将任何可以解释为对象引用的局部都清零来帮助GC。否则，GC可能最终会在尚未设置的本地中看到一个垃圾值，并假定它引用的是有效对象，这时可能会发生“bad things”。参考当地人越多，需要进行的清理越多。如果您只清理一些当地人，那可能不会引起注意。但是随着数量的增加，清除这些本地对象所花费的时间可能加起来，尤其是在非常热的代码路径中使用的一种小方法中。这种情况在跨度和结构中变得更加普遍，在这种情况下，编码模式通常会导致需要为零的更多引用（Span 包含引用）。前面提到的PR通过更新JIT生成的序号块的代码来解决此问题，这些序号块使用xmm寄存器而不是rep stosd指令来执行该清零操作。有效地，它对归零进行矢量化处理。您可以通过以下基准测试看到此影响：

[Benchmark]
public int Zeroing()
{
    ReadOnlySpan s1 = "hello world";
    ReadOnlySpan s2 = Nop(s1);
    ReadOnlySpan s3 = Nop(s2);
    ReadOnlySpan s4 = Nop(s3);
    ReadOnlySpan s5 = Nop(s4);
    ReadOnlySpan s6 = Nop(s5);
    ReadOnlySpan s7 = Nop(s6);
    ReadOnlySpan s8 = Nop(s7);
    ReadOnlySpan s9 = Nop(s8);
    ReadOnlySpan s10 = Nop(s9);
    return s1.Length + s2.Length + s3.Length + s4.Length + s5.Length + s6.Length + s7.Length + s8.Length + s9.Length + s10.Length;
}

[MethodImpl(MethodImplOptions.NoInlining)]
private static ReadOnlySpan Nop(ReadOnlySpan span) => default;

在我的机器上，我得到如下结果:

Method	Runtime	Mean	Ratio
Zeroing	.NET FW 4.8	22.85 ns	1.00
Zeroing	.NET Core 3.1	18.60 ns	0.81
Zeroing	.NET 5.0	15.07 ns	0.66

请注意，这种零实际上需要在比我提到的更多的情况下。特别是，默认情况下，c#规范要求在执行开发人员的代码之前，将所有本地变量初始化为默认值。你可以通过这样一个例子来了解这一点:

using System;
using System.Runtime.CompilerServices;
using System.Threading;

unsafe class Program
{
    static void Main()
    {
        while (true)
        {
            Example();
            Thread.Sleep(1);
        }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Example()
    {
        Guid g;
        Console.WriteLine(*&g);
    }
}

运行它，您应该只看到所有0输出的guid。这是因为c#编译器在编译的示例方法的IL中发出一个.locals init标志，而.locals init告诉JIT它需要将所有的局部变量归零，而不仅仅是那些包含引用的局部变量。然而，在.NET 5中，运行时中有一个新属性(dotnet/runtime#454):

namespace System.Runtime.CompilerServices
{
    [AttributeUsage(AttributeTargets.Module | AttributeTargets.Class | AttributeTargets.Struct | AttributeTargets.Constructor | AttributeTargets.Method | AttributeTargets.Property | AttributeTargets.Event | AttributeTargets.Interface, Inherited = false)]
    public sealed class SkipLocalsInitAttribute : Attribute { }
}

c#编译器可以识别这个属性，它用来告诉编译器在其他情况下不发出.locals init。如果我们对前面的示例稍加修改，就可以将属性添加到整个模块中：

using System;
using System.Runtime.CompilerServices;
using System.Threading;

[module: SkipLocalsInit]

unsafe class Program
{
    static void Main()
    {
        while (true)
        {
            Example();
            Thread.Sleep(1);
        }
    }

    [MethodImpl(MethodImplOptions.NoInlining)]
    static void Example()
    {
        Guid g;
        Console.WriteLine(*&g);
    }
}

现在应该会看到不同的结果，特别是很可能会看到非零的guid。在dotnet/runtime#37541中，.NET5 中的核心库现在都使用这个属性来禁用.locals init(在以前的版本中，.locals init在构建核心库时通过编译后的一个步骤删除)。请注意，c#编译器只允许在不安全的上下文中使用SkipLocalsInit，因为它很容易导致未经过适当验证的代码损坏(因此，如果/当您应用它时，请三思)。

除了使零的速度更快，也有改变，以消除零完全。例如，dotnet/runtime#31960, dotnet/runtime#36918, dotnet/runtime#37786,和dotnet/runtime#38314 都有助于消除零，当JIT可以证明它是重复的。
这样的零是托管代码的一个例子，运行时需要它来保证其模型和上面语言的需求。另一种此类税收是边界检查。使用托管代码的最大优势之一是，在默认情况下，整个类的潜在安全漏洞都变得无关紧要。运行时确保数组、字符串和span的索引被检查，这意味着运行时注入检查以确保被请求的索引在被索引的数据的范围内(即greather大于或等于0，小于数据的长度)。这里有一个简单的例子:

public static char Get(string s, int i) => s[i];

为了保证这段代码的安全，运行时需要生成一个检查，检查i是否在字符串s的范围内，这是JIT通过如下程序集完成的:

; Program.Get(System.String, Int32)
       sub       rsp,28
       cmp       edx,[rcx+8]
       jae       short M01_L00
       movsxd    rax,edx
       movzx     eax,word ptr [rcx+rax*2+0C]
       add       rsp,28
       ret
M01_L00:
       call      CORINFO_HELP_RNGCHKFAIL
       int       3
; Total bytes of code 28

这个程序集是通过Benchmark的一个方便特性生成的。将[DisassemblyDiagnoser]添加到包含基准测试的类中，它就会吐出被分解的汇编代码。我们可以看到,大会将字符串(通过rcx寄存器)和加载字符串的长度(8个字节存储到对象,因此,[rcx + 8]),与我经过比较,edx登记,如果与一个无符号的比较(无符号,这样任何负环绕大于长度)我是长度大于或等于,跳到一个辅助COREINFO_HELP_RNGCHKFAIL抛出一个异常。只有几条指令，但是某些类型的代码可能会花费大量的循环索引，因此，当JIT可以消除尽可能多的不必要的边界检查时，这是很有帮助的。
JIT已经能够在各种情况下删除边界检查。例如，当你写循环:

int[] arr = ...;
for (int i = 0; i < arr.Length; i++)
    Use(arr[i]);

JIT可以证明我永远不会超出数组的边界，因此它可以省略它将生成的边界检查。在.NET5 中，它可以在更多的地方删除边界检查。例如，考虑这个函数，它将一个整数的字节作为字符写入一个span:

private static bool TryToHex(int value, Span span)
{
    if ((uint)span.Length <= 7)
        return false;

    ReadOnlySpan map = new byte[] { (byte)'0', (byte)'1', (byte)'2', (byte)'3', (byte)'4', (byte)'5', (byte)'6', (byte)'7', (byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C', (byte)'D', (byte)'E', (byte)'F' }; ;
    span[0] = (char)map[(value >> 28) & 0xF];
    span[1] = (char)map[(value >> 24) & 0xF];
    span[2] = (char)map[(value >> 20) & 0xF];
    span[3] = (char)map[(value >> 16) & 0xF];
    span[4] = (char)map[(value >> 12) & 0xF];
    span[5] = (char)map[(value >> 8) & 0xF];
    span[6] = (char)map[(value >> 4) & 0xF];
    span[7] = (char)map[value & 0xF];
    return true;
}

private char[] _buffer = new char[100];

[Benchmark]
public bool BoundsChecking() => TryToHex(int.MaxValue, _buffer);

首先，在这个例子中，值得注意的是我们依赖于c#编译器的优化。注意:

ReadOnlySpan map = new byte[] { (byte)'0', (byte)'1', (byte)'2', (byte)'3', (byte)'4', (byte)'5', (byte)'6', (byte)'7', (byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C', (byte)'D', (byte)'E', (byte)'F' };

这看起来非常昂贵，就像我们在每次调用TryToHex时都要分配一个字节数组。事实上，它并不是这样的，它实际上比我们做的更好:

private static readonly byte[] s_map = new byte[] { (byte)'0', (byte)'1', (byte)'2', (byte)'3', (byte)'4', (byte)'5', (byte)'6', (byte)'7', (byte)'8', (byte)'9', (byte)'A', (byte)'B', (byte)'C', (byte)'D', (byte)'E', (byte)'F' };
...
ReadOnlySpan map = s_map;

C#编译器可以识别直接分配给ReadOnlySpan的新字节数组的模式(它也可以识别sbyte和bool，但由于字节关系，没有比字节大的)。因为数组的性质被span完全隐藏了，C#编译器通过将字节实际存储到程序集的数据部分而发出这些字节，而span只是通过将静态数据和长度的指针包装起来而创建的:

IL_000c: ldsflda valuetype ''/'__StaticArrayInitTypeSize=16' ''::'2125B2C332B1113AAE9BFC5E9F7E3B4C91D828CB942C2DF1EEB02502ECCAE9E9'
IL_0011: ldc.i4.s 16
IL_0013: newobj instance void valuetype [System.Runtime]System.ReadOnlySpan'1::.ctor(void*, int32)

由于ldc.i4，这对于本次JIT讨论很重要。s16在上面。这就是IL加载16的长度来创建跨度，JIT可以看到这一点。它知道跨度的长度是16，这意味着如果它可以证明访问总是大于或等于0且小于16的值，它就不需要对访问进行边界检查。dotnet/runtime#1644 就是这样做的，它可以识别像array[index % const]这样的模式，并在const小于或等于长度时省略边界检查。在前面的TryToHex示例中,JIT可以看到地图跨长度16,和它可以看到所有的索引到完成& 0 xf,意义最终将所有值在范围内,因此它可以消除所有的边界检查地图。结合的事实可能已经看到,没有边界检查需要写进跨度(因为它可以看到前面长度检查的方法保护所有索引到跨度),和整个方法是在.NET bounds-check-free 5。在我的机器上，这个基准测试的结果如下:

Method	Runtime	Mean	Ratio	Code Size
BoundsChecking	.NET FW 4.8	14.466 ns	1.00	830 B
BoundsChecking	.NET Core 3.1	4.264 ns	0.29	320 B
BoundsChecking	.NET 5.0	3.641 ns	0.25	249 B

注意.NET5的运行速度不仅比.NET Core 3.1快15%，我们还可以看到它的汇编代码大小小了22%(额外的“Code Size”一栏来自于我在benchmark类中添加了[DisassemblyDiagnoser])。
另一个很好的边界检查移除来自dotnet/runtime#36263中的@nathan-moore。我提到过，JIT已经能够删除非常常见的从0迭代到数组、字符串或span长度的模式的边界检查，但是在此基础上还有一些比较常见的变化，但以前没有认识到。例如，考虑这个微基准测试，它调用一个方法来检测一段整数是否被排序:

private int[] _array = Enumerable.Range(0, 1000).ToArray();

[Benchmark]
public bool IsSorted() => IsSorted(_array);

private static bool IsSorted(ReadOnlySpan span)
{
    for (int i = 0; i < span.Length - 1; i++)
        if (span[i] > span[i + 1])
            return false;

    return true;
}

这种与以前识别的模式的微小变化足以防止JIT忽略边界检查。现在不是了.NET5在我的机器上可以快20%的执行:

Method	Runtime	Mean	Ratio	Code Size
IsSorted	.NET FW 4.8	1,083.8 ns	1.00	236 B
IsSorted	.NET Core 3.1	581.2 ns	0.54	136 B
IsSorted	.NET 5.0	463.0 ns	0.43	105 B

JIT确保对某个错误类别进行检查的另一种情况是空检查。JIT与运行时协同完成这一任务，JIT确保有适当的指令来引发硬件异常，然后与运行时一起将这些错误转换为.NET异常(这里))。但有时指令只用于null检查，而不是完成其他必要的功能，而且只要需要的null检查是由于某些指令发生的，不必要的重复指令可以被删除。考虑这段代码:

private (int i, int j) _value;

[Benchmark]
public int NullCheck() => _value.j++;

作为一个可运行的基准测试，它所做的工作太少，无法用基准测试进行准确的度量.NET，但这是查看生成的汇编代码的好方法。在.NET Core 3.1中，此方法产生如下assembly:

; Program.NullCheck()
       nop       dword ptr [rax+rax]
       cmp       [rcx],ecx
       add       rcx,8
       add       rcx,4
       mov       eax,[rcx]
       lea       edx,[rax+1]
       mov       [rcx],edx
       ret
; Total bytes of code 23

cmp [rcx]，ecx指令在计算j的地址时执行null检查，然后mov eax，[rcx]指令执行另一个null检查，作为取消引用j的位置的一部分。因此，第一个null检查实际上是不必要的，因为该指令没有提供任何其他好处。所以，多亏了像dotnet/runtime#1735和dotnet/runtime#32641这样的PRs，这样的重复被JIT比以前更多地识别，对于.NET 5，我们现在得到了:

; Program.NullCheck()
       add       rcx,0C
       mov       eax,[rcx]
       lea       edx,[rax+1]
       mov       [rcx],edx
       ret
; Total bytes of code 12

协方差是JIT需要注入检查以确保开发人员不会意外地破坏类型或内存安全性的另一种情况。考虑一下代码

class A { }
class B { }
object[] arr = ...;
arr[0] = new A();

这个代码有效吗?视情况而定。.NET中的数组是“协变”的，这意味着我可以传递一个数组派生类型[]作为BaseType[]，其中派生类型派生自BaseType。这意味着在本例中，arr可以被构造为新A[1]或新对象[1]或新B[1]。这段代码应该在前两个中运行良好，但如果arr实际上是一个B[]，试图存储一个实例到其中必须失败;否则，使用数组作为B[]的代码可能尝试使用B[0]作为B，事情可能很快就会变得很糟糕。因此，运行时需要通过协方差检查来防止这种情况发生，这实际上意味着当引用类型实例存储到数组中时，运行时需要检查所分配的类型实际上与数组的具体类型兼容。使用dotnet/runtime#189, JIT现在能够消除更多的协方差检查，特别是在数组的元素类型是密封的情况下，比如string。因此，像这样的微基准现在运行得更快了:

private string[] _array = new string[1000];

[Benchmark]
public void CovariantChecking()
{
    string[] array = _array;
    for (int i = 0; i < array.Length; i++)
        array[i] = "default";
}

Method	Runtime	Mean	Ratio	Code Size
CovariantChecking	.NET FW 4.8	2.121 us	1.00	57 B
CovariantChecking	.NET Core 3.1	2.122 us	1.00	57 B
CovariantChecking	.NET 5.0	1.666 us	0.79	52 B

与此相关的是类型检查。我之前提到过Span 解决了很多问题，但也引入了新的模式，从而推动了系统其他领域的改进;对于Span 本身的实现也是这样。 Span 构造函数做协方差检查，要求T[]实际上是T[]而不是U[]，其中U源自T，例如:

using System;

class Program
{
    static void Main() => new Span(new B[42]);
}

class A { }
class B : A { }

将导致异常:

System.ArrayTypeMismatchException: Attempted to access an element as a type incompatible with the array

该异常源于对Span 的构造函数的检查：

if (!typeof(T).IsValueType && array.GetType() != typeof(T[]))
    ThrowHelper.ThrowArrayTypeMismatchException();

PR dotnet/runtime#32790就是这样优化数组的.GetType()！= typeof(T [])检查何时密封T，而dotnet/runtime#1157识别typeof(T).IsValueType模式并将其替换为常量值（PR dotnet/runtime#1195对于typeof(T1).IsAssignableFrom(typeof(T2))进行了相同的操作）。这样做的最终结果是极大地改善了微基准，例如：

class A { }
sealed class B : A { }

private B[] _array = new B[42];

[Benchmark]
public int Ctor() => new Span(_array).Length;

Method	Runtime	Mean	Ratio	Code Size
Ctor	.NET FW 4.8	48.8670 ns	1.00	66 B
Ctor	.NET Core 3.1	7.6695 ns	0.16	66 B
Ctor	.NET 5.0	0.4959 ns	0.01	17 B

Method	Runtime	Mean	Ratio
Compare	.NET FW 4.8	8.632 ns	1.00
Compare	.NET Core 3.1	9.259 ns	1.07
Compare	.NET 5.0	5.282 ns	0.61

Method	Runtime	Code Size
Throw helpers	.NET FW 4.8	424 B
Throw helpers	.NET Core 3.1	252 B
Throw helpers	.NET 5.0	222 B

Method	Runtime	Mean	Ratio	Code Size
IsIReadOnlyCollection	.NET FW 4.8	105.460 ns	1.00	53 B
IsIReadOnlyCollection	.NET Core 3.1	56.252 ns	0.53	59 B
IsIReadOnlyCollection	.NET 5.0	3.383 ns	0.03	45 B

Method	Runtime	Mean	Ratio
GenericDictionaries	.NET FW 4.8	104.33 ns	1.00
GenericDictionaries	.NET Core 3.1	76.71 ns	0.74
GenericDictionaries	.NET 5.0	51.53 ns	0.49

Method	Runtime	Mean	Ratio	Code Size
Trim	.NET FW 4.8	21.694 ns	1.00	569 B
Trim	.NET Core 3.1	8.079 ns	0.37	377 B
Trim	.NET 5.0	6.556 ns	0.30	365 B

Method	Runtime	Mean	Ratio	Code Size
ToUpperInvariant	.NET FW 4.8	208.34 ns	1.00	171 B
ToUpperInvariant	.NET Core 3.1	166.10 ns	0.80	164 B
ToUpperInvariant	.NET 5.0	69.15 ns	0.33	105 B

Method	Runtime	Mean	Ratio	Allocated
ToString12345	.NET FW 4.8	45.737 ns	1.00	40 B
ToString12345	.NET Core 3.1	20.006 ns	0.44	32 B
ToString12345	.NET 5.0	10.742 ns	0.23	32 B

ToString123	.NET FW 4.8	42.791 ns	1.00	32 B
ToString123	.NET Core 3.1	18.014 ns	0.42	32 B
ToString123	.NET 5.0	7.801 ns	0.18	32 B

Method	Runtime	Mean	Ratio
FormatChars	.NET Core 3.1	242.4 ns	1.00
FormatChars	.NET 5.0	176.4 ns	0.73

FormatBytes	.NET Core 3.1	235.6 ns	1.00
FormatBytes	.NET 5.0	176.1 ns	0.75

Method	Runtime	Mean	Ratio	Allocated
Roundtrip	.NET FW 4.8	113.69 ns	1.00	96 B
Roundtrip	.NET Core 3.1	49.76 ns	0.44	96 B
Roundtrip	.NET 5.0	36.70 ns	0.32	96 B

Method	Runtime	Mean	Allocated
Roundtrip	.NET FW 4.8	221.85 ns	209 B
Roundtrip	.NET Core 3.1	193.20 ns	200 B
Roundtrip	.NET 5.0	41.76 ns	200 B

Method	Runtime	Compiled	Mean	Ratio
Count	.NET FW 4.8	False	26.207 ms	1.00
Count	.NET Core 3.1	False	21.106 ms	0.80
Count	.NET 5.0	False	4.065 ms	0.16

Count	.NET FW 4.8	True	16.944 ms	1.00
Count	.NET Core 3.1	True	15.287 ms	0.90
Count	.NET 5.0	True	2.172 ms	0.13

Method	Runtime	Mean	Ratio
IsMatch	.NET FW 4.8	2,558.1 ns	1.00
IsMatch	.NET Core 3.1	789.3 ns	0.31
IsMatch	.NET 5.0	129.0 ns	0.05

Method	Runtime	Mean	Ratio
IsMatch	.NET FW 4.8	712.9 ns	1.00
IsMatch	.NET Core 3.1	343.5 ns	0.48
IsMatch	.NET 5.0	100.9 ns	0.14

Method	Runtime	Mean	Ratio
Email	.NET FW 4.8	1,036.729 ms	1.00
Email	.NET Core 3.1	930.238 ms	0.90
Email	.NET 5.0	50.911 ms	0.05

Uri	.NET FW 4.8	870.114 ms	1.00
Uri	.NET Core 3.1	759.079 ms	0.87
Uri	.NET 5.0	50.022 ms	0.06

IP	.NET FW 4.8	75.718 ms	1.00
IP	.NET Core 3.1	61.818 ms	0.82
IP	.NET 5.0	6.837 ms	0.09

Method	Runtime	Mean	Ratio	Allocated
ValueTaskCost	.NET FW 4.8	1,635.6 us	1.00	294010 B
ValueTaskCost	.NET Core 3.1	842.7 us	0.51	120184 B
ValueTaskCost	.NET 5.0	812.3 us	0.50	186 B

Method	Runtime	Mean	Ratio	Allocated
Cancel	.NET FW 4.8	239.2 ns	1.00	193 B
Cancel	.NET Core 3.1	140.3 ns	0.59	192 B
Cancel	.NET 5.0	106.4 ns	0.44	112 B

Method	Runtime	Mean	Ratio
Sum	.NET FW 4.8	77.45 us	1.00
Sum	.NET Core 3.1	67.35 us	0.87
Sum	.NET 5.0	44.10 us	0.57

Method	Runtime	Mean	Ratio
Sum	.NET FW 4.8	76.29 us	1.00
Sum	.NET Core 3.1	79.23 us	1.04
Sum	.NET 5.0	42.63 us	0.56

Method	Runtime	Mean	Ratio
Sum	.NET FW 4.8	115.25 us	1.00
Sum	.NET Core 3.1	84.30 us	0.73
Sum	.NET 5.0	49.52 us	0.43

Method	Runtime	Mean	Ratio
Sum	.NET FW 4.8	187.60 us	1.00
Sum	.NET Core 3.1	187.32 us	1.00
Sum	.NET 5.0	46.59 us	0.25

Method	Runtime	Mean	Ratio
Sum	.NET FW 4.8	22.259 ms	1.00
Sum	.NET Core 3.1	22.872 ms	1.03
Sum	.NET 5.0	2.066 ms	0.09

Method	Runtime	Mean	Ratio
Create	.NET FW 4.8	1,140.91 ns	1.00
Create	.NET Core 3.1	861.97 ns	0.76
Create	.NET 5.0	49.08 ns	0.04

Method	Runtime	Mean	Ratio
Sort	.NET FW 4.8	100.78 us	1.00
Sort	.NET Core 3.1	101.03 us	1.00
Sort	.NET 5.0	85.46 us	0.85

Method	Runtime	Mean	Ratio	Allocated
SkipLast	.NET Core 3.1	1,641.0 ns	1.00	248 B
SkipLast	.NET 5.0	684.8 ns	0.42	48 B

Method	Runtime	Mean	Ratio	Allocated
Ctor	.NET FW 4.8	443.2 ns	1.00	225 B
Ctor	.NET Core 3.1	192.3 ns	0.43	72 B
Ctor	.NET 5.0	129.9 ns	0.29	56 B

Method	Runtime	Mean	Ratio	Allocated
PathAndQuery	.NET FW 4.8	17.936 ns	1.00	56 B
PathAndQuery	.NET Core 3.1	30.891 ns	1.72	56 B
PathAndQuery	.NET 5.0	2.854 ns	0.16	–

Method	Runtime	ASCII	Mean	Ratio	Allocated
Escape	.NET FW 4.8	False	6,162.59 us	1.00	60616272 B
Escape	.NET Core 3.1	False	6,483.85 us	1.06	60612025 B
Escape	.NET 5.0	False	243.09 us	0.04	240045 B

Escape	.NET FW 4.8	True	86.93 us	1.00	–
Escape	.NET Core 3.1	True	122.06 us	1.40	–
Escape	.NET 5.0	True	14.04 us	0.16	–

Method	Runtime	Mean	Ratio
Unescape	.NET FW 4.8	847.44 ns	1.00
Unescape	.NET Core 3.1	846.84 ns	1.00
Unescape	.NET 5.0	21.84 ns	0.03

Method	Runtime	Mean	Ratio
Sum	.NET FW 4.8	330.25 us	1.00
Sum	.NET Core 3.1	47.64 us	0.14
Sum	.NET 5.0	18.87 us	0.06

Method	Runtime	Mean	Ratio	Allocated
SendReceive	.NET Core 3.1	5.924 us	1.00	624 B
SendReceive	.NET 5.0	5.230 us	0.88	144 B

Method	Runtime	Mean	Ratio	Allocated
HttpGet	.NET FW 4.8	123.67 us	1.00	98.48 KB
HttpGet	.NET Core 3.1	68.57 us	0.55	6.07 KB
HttpGet	.NET 5.0	66.80 us	0.54	2.86 KB

Method	Runtime	Mean	Ratio	Allocated
DatePreferred	.NET FW 4.8	2,177.9 ns	1.00	674 B
DatePreferred	.NET Core 3.1	1,510.8 ns	0.69	544 B
DatePreferred	.NET 5.0	267.2 ns	0.12	520 B

Method	Runtime	Mean	Ratio	Allocated
Get	.NET Core 3.1	1,267.4 ms	1.00	122.76 MB
Get	.NET 5.0	681.7 ms	0.54	74.01 MB

Post	.NET Core 3.1	1,464.7 ms	1.00	280.51 MB
Post	.NET 5.0	735.6 ms	0.50	132.52 MB

Method	Runtime	Mean	Ratio	Allocated
Lookup	.NET FW 4.8	178.6 us	1.00	4146 B
Lookup	.NET Core 3.1	211.5 us	1.18	1664 B
Lookup	.NET 5.0	209.7 us	1.17	984 B

Method	Runtime	Mean	Ratio	Allocated
WriteRead	.NET Core 3.1	1.510 ms	1.00	61600 B
WriteRead	.NET 5.0	1.294 ms	0.86	–

ReadWrite	.NET Core 3.1	3.502 ms	1.00	76224 B
ReadWrite	.NET 5.0	3.301 ms	0.94	226 B

Method	Runtime	Mean	Ratio	Allocated
LargeArray	.NET FW 4.8	262.06 us	1.00	24256 B
LargeArray	.NET Core 3.1	191.34 us	0.73	24184 B
LargeArray	.NET 5.0	69.40 us	0.26	152 B

Method	Runtime	Mean	Ratio	Allocated
Dictionary	.NET FW 4.8	2,141.7 ns	1.00	209 B
Dictionary	.NET Core 3.1	1,376.6 ns	0.64	208 B
Dictionary	.NET 5.0	726.1 ns	0.34	152 B

Method	Runtime	Mean	Ratio	Allocated
SimpleType	.NET FW 4.8	1,204.3 ns	1.00	265 B
SimpleType	.NET Core 3.1	617.2 ns	0.51	192 B
SimpleType	.NET 5.0	504.2 ns	0.42	192 B

Method	Runtime	Mean	Ratio	Allocated
OneAlreadyCompleted	.NET FW 4.8	125.387 ns	1.00	217 B
OneAlreadyCompleted	.NET Core 3.1	89.040 ns	0.71	200 B
OneAlreadyCompleted	.NET 5.0	8.391 ns	0.07	72 B

AsyncCompletion	.NET FW 4.8	289.042 ns	1.00	257 B
AsyncCompletion	.NET Core 3.1	195.879 ns	0.68	240 B
AsyncCompletion	.NET 5.0	150.523 ns	0.52	160 B

Method	Mean	Ratio	Allocated
Slice1	8.3337 ns	1.00	32 B
Slice2	0.4332 ns	0.05	–

Method	Mean	Ratio	Allocated
ReadWrite1	7.604 ms	1.00	72001 B
ReadWrite2	7.549 ms	0.99	–

Method	Mean	Ratio	Allocated
Append1	13.546 us	1.00	31680 B
Append2	9.841 us	0.73	–

Method	Mean	Ratio
Append1	2.621 us	1.00
Append2	1.968 us	0.75

Method	Mean	Ratio
IsEmpty1	21.621 ns	1.00
IsEmpty2	4.041 ns	0.19

【翻译】.NET 5中的性能改进

【翻译】.NET 5中的性能改进

安装

GC

JIT

Intrinsics

Runtime helpers

Text Processing

Regular Expressions

Threading and Async

Collections

LINQ

Networking

JSON

Trimming

Peanut Butter

New Performance-focused APIs

New Performance-focused Analyzers

What's Next?

你可能感兴趣的:(【翻译】.NET 5中的性能改进)