【翻譯】.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的內容擴展為如下所示：

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <AllowUnsafeBlocks>true</AllowUnsafeBlocks>
    <ServerGarbageCollection>true</ServerGarbageCollection>
    <TargetFrameworks>net5.0;netcoreapp3.1;net48</TargetFrameworks>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="benchmarkdotnet" Version="0.12.1" />
  </ItemGroup>

  <ItemGroup Condition=" '$(TargetFramework)' == 'net48' ">
    <PackageReference Include="System.Memory" Version="4.5.4" />
    <PackageReference Include="System.Text.Json" Version="4.7.2" />
    <Reference Include="System.Net.Http" />
  </ItemGroup>

</Project>

這樣，就可以針對.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<double> { protected override double GetNext() => _random.Next(); }
public class Int32Sorting : Sorting<int> { protected override int GetNext() => _random.Next(); }
public class StringSorting : Sorting<string>
{
    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<T>
{
    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);
    }
}

這本身就是這次遷移的一個很好的好處，因為我們在.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上運行時，我得到的秒數是這樣的

6.6419048
5.5663149
5.7430339
6.032052
7.8892468

在這裡，GC很難中斷執行排序的線程，導致GC暫停時間遠遠高於預期。幸運的是，當我在 .NET5 上運行這個時，我得到了這樣的數字:

0.159311
0.159453
0.1594669
0.1593328
0.1586566

這正是我們預測的結果。通過移動數組。將實現排序到托管代碼中，這樣運行時就可以在需要時更容易地掛起實現，我們使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<char> s1 = "hello world";
    ReadOnlySpan<char> s2 = Nop(s1);
    ReadOnlySpan<char> s3 = Nop(s2);
    ReadOnlySpan<char> s4 = Nop(s3);
    ReadOnlySpan<char> s5 = Nop(s4);
    ReadOnlySpan<char> s6 = Nop(s5);
    ReadOnlySpan<char> s7 = Nop(s6);
    ReadOnlySpan<char> s8 = Nop(s7);
    ReadOnlySpan<char> s9 = Nop(s8);
    ReadOnlySpan<char> 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<char> Nop(ReadOnlySpan<char> span) => default;

在我的機器上，我得到如下結果:

請註意，這種零實際上需要在比我提到的更多的情況下。特別是，預設情況下，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<char> span)
{
    if ((uint)span.Length <= 7)
        return false;

    ReadOnlySpan<byte> 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<byte> 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<byte> map = s_map;

C#編譯器可以識別直接分配給ReadOnlySpan的新位元組數組的模式(它也可以識別sbyte和bool，但由於位元組關係，沒有比位元組大的)。因為數組的性質被span完全隱藏了，C#編譯器通過將位元組實際存儲到程式集的數據部分而發出這些位元組，而span只是通過將靜態數據和長度的指針包裝起來而創建的:

IL_000c: ldsflda valuetype '<PrivateImplementationDetails>'/'__StaticArrayInitTypeSize=16' '<PrivateImplementationDetails>'::'2125B2C332B1113AAE9BFC5E9F7E3B4C91D828CB942C2DF1EEB02502ECCAE9E9'
IL_0011: ldc.i4.s 16
IL_0013: newobj instance void valuetype [System.Runtime]System.ReadOnlySpan'1<uint8>::.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。在我的機器上，這個基準測試的結果如下:

註意.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<int> span)
{
    for (int i = 0; i < span.Length - 1; i++)
        if (span[i] > span[i + 1])
            return false;

    return true;
}

這種與以前識別的模式的微小變化足以防止JIT忽略邊界檢查。現在不是了.NET5在我的機器上可以快20%的執行:

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";
}

與此相關的是類型檢查。我之前提到過Span解決了很多問題，但也引入了新的模式，從而推動了系統其他領域的改進;對於Span本身的實現也是這樣。 Span 構造函數做協方差檢查，要求T[]實際上是T[]而不是U[]，其中U源自T，例如:

using System;

class Program
{
    static void Main() => new Span<A>(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<B>(_array).Length;

我得到的結果如下:

當查看生成的程式集時，差異的解釋就很明顯了，即使不是完全精通程式集代碼。以下是[DisassemblyDiagnoser]在.NET Core 3.1上生成的內容:

; Program.Ctor()
       push      rdi
       push      rsi
       sub       rsp,28
       mov       rsi,[rcx+8]
       test      rsi,rsi
       jne       short M00_L00
       xor       eax,eax
       jmp       short M00_L01
M00_L00:
       mov       rcx,rsi
       call      System.Object.GetType()
       mov       rdi,rax
       mov       rcx,7FFE4B2D18AA
       call      CORINFO_HELP_TYPEHANDLE_TO_RUNTIMETYPE
       cmp       rdi,rax
       jne       short M00_L02
       mov       eax,[rsi+8]
M00_L01:
       add       rsp,28
       pop       rsi
       pop       rdi
       ret
M00_L02:
       call      System.ThrowHelper.ThrowArrayTypeMismatchException()
       int       3
; Total bytes of code 66

下麵是.NET5的內容:

; Program.Ctor()
       mov       rax,[rcx+8]
       test      rax,rax
       jne       short M00_L00
       xor       eax,eax
       jmp       short M00_L01
M00_L00:
       mov       eax,[rax+8]
M00_L01:
       ret
; Total bytes of code 17

另一個例子是，在前面的GC討論中，我提到了將本地運行時代碼移植到c#代碼中所帶來的一些好處。有一點我之前沒有提到，但現在將會提到，那就是它導致了我們對系統進行了其他改進，解決了移植的關鍵阻滯劑，但也改善了許多其他情況。一個很好的例子是dotnet/runtime#38229。當我們第一次將本機數組排序實現移動到managed時，我們無意中導致了浮點值的回歸，這個回歸被@nietras 發現，隨後在dotnet/runtime#37941中修複。回歸是由於本機實現使用一個特殊的優化,我們失蹤的管理埠(浮點數組,將所有NaN值數組的開始,後續的比較操作可以忽略NaN)的可能性,我們成功了。然而,問題是這個的方式表達並沒有導致大量的代碼重覆:本機實現模板,使用和管理實現使用泛型,但限制與泛型等,內聯 helpers介紹,以避免大量的代碼重覆導致non-inlineable在每個比較採用那種方法調用。PR dotnet/runtime#38229通過允許JIT在同一類型內嵌共用泛型代碼解決了這個問題。考慮一下這個微基準測試:

private C c1 = new C() { Value = 1 }, c2 = new C() { Value = 2 }, c3 = new C() { Value = 3 };

[Benchmark]
public int Compare() => Comparer<C>.Smallest(c1, c2, c3);

class Comparer<T> where T : IComparable<T>
{
    public static int Smallest(T t1, T t2, T t3) =>
        Compare(t1, t2) <= 0 ?
            (Compare(t1, t3) <= 0 ? 0 : 2) :
            (Compare(t2, t3) <= 0 ? 1 : 2);

    [MethodImpl(MethodImplOptions.AggressiveInlining)]
    private static int Compare(T t1, T t2) => t1.CompareTo(t2);
}

class C : IComparable<C>
{
    public int Value;
    public int CompareTo(C other) => other is null ? 1 : Value.CompareTo(other.Value);
}

最小的方法比較提供的三個值並返回最小值的索引。它是泛型類型上的一個方法，它調用同一類型上的另一個方法，這個方法反過來調用泛型類型參數實例上的方法。由於基準使用C作為泛型類型，而且C是引用類型，所以JIT不會專門為C專門化此方法的代碼，而是使用它生成的用於所有引用類型的“shared”實現。為了讓Compare方法隨後調用到CompareTo的正確介面實現，共用泛型實現使用了一個從泛型類型映射到正確目標的字典。在. net的早期版本中，包含那些通用字典查找的方法是不可行的，這意味著這個最小的方法不能內聯它所做的三個比較調用，即使Compare被歸為methodimploptions .侵略化的內聯。前面提到的PR消除了這個限制，在這個例子中產生了一個非常可測量的加速(並使數組排序回歸修複可行):

這裡提到的大多數改進都集中在吞吐量上，JIT產生的代碼執行得更快，而更快的代碼通常(儘管不總是)更小。從事JIT工作的人們實際上非常關註代碼大小，在許多情況下，將其作為判斷更改是否有益的主要指標。更小的代碼並不總是更快的代碼(可以是相同大小的指令，但開銷不同)，但從高層次上來說，這是一個合理的度量，更小的代碼確實有直接的好處，比如對指令緩存的影響更小，需要載入的代碼更少，等等。在某些情況下，更改完全集中在減少代碼大小上，比如在出現不必要的重覆的情況下。考慮一下這個簡單的基準:

private int _offset = 0;

[Benchmark]
public int Throw helpers()
{
    var arr = new int[10];
    var s0 = new Span<int>(arr, _offset, 1);
    var s1 = new Span<int>(arr, _offset + 1, 1);
    var s2 = new Span<int>(arr, _offset + 2, 1);
    var s3 = new Span<int>(arr, _offset + 3, 1);
    var s4 = new Span<int>(arr, _offset + 4, 1);
    var s5 = new Span<int>(arr, _offset + 5, 1);
    return s0[0] + s1[0] + s2[0] + s3[0] + s4[0] + s5[0];
}

Span構造函數參數驗證,,T是一個值類型時,結果有兩個叫網站ThrowHelper類上的方法,一個扔一個失敗的null檢查時拋出的輸入數組和一個偏移量和計數的範圍(像ThrowArgumentNullException ThrowHelper包含non-inlinable方法,其中包含實際的扔,避免了相關代碼大小在每個調用網站;JIT目前還不能“outlining”(與“inlining”相反)，因此需要在重要的情況下手工完成)。在上面的示例中，我們創建了6個Span，這意味著對Span構造函數的6次調用，所有這些調用都將內聯。JIT數組為空,所以它可以消除零檢查和ThrowArgumentNullException內聯代碼,但是它不知道是否偏移量和計算範圍內,因此它需要保留ThrowHelper範圍檢查和調用站點。ThrowArgumentOutOfRangeException方法。在.NET Core 3.1中，這個Throw helpers方法生成瞭如下代碼:

M00_L00:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3
M00_L01:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3
M00_L02:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3
M00_L03:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3
M00_L04:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3
M00_L05:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3

在.NET 5中，感謝dotnet/coreclr#27113, JIT能夠識別這種重覆，而不是所有的6個呼叫站點，它將最終合併成一個:

M00_L00:
       call      System.ThrowHelper.ThrowArgumentOutOfRangeException()
       int       3

所有失敗的檢查都跳到這個共用位置，而不是每個都有自己的副本

這些只是.NET 5中對JIT進行的眾多改進中的一部分。還有許多其他改進。dotnet/runtime#32368導致JIT將數組的長度視為無符號，這使得JIT能夠對在長度上執行的某些數學運算（例如除法）使用更好的指令。 dotnet/runtime#25458 使JIT可以對某些無符號整數運算使用更快的基於0的比較。 當開發人員實際編寫> = 1時，使用等於！= 0的值。dotnet/runtime#1378允許JIT將“ constantString” .Length識別為常量值。 dotnet/runtime#26740 通過刪除nop填充來減小ReadyToRun圖像的大小。 dotnet/runtime#330234使用加法而不是乘法來優化當x為浮點數或雙精度數時執行x * 2時生成的指令。dotnet/runtime#27060改進了為Math.FusedMultiplyAdd內部函數生成的代碼。 dotnet/runtime#27384通過使用比以前更好的籬笆指令使ARM64上的易失性操作便宜，並且dotnet/runtime#38179在ARM64上執行窺視孔優化以刪除大量冗餘mov指令。 等等。


JIT中還有一些預設禁用的重要更改，目的是獲得關於它們的真實反饋，並能夠在預設情況下post-啟用它們。凈5。例如，dotnet/runtime#32969提供了“On Stack Replacement”(OSR)的初始實現。我在前面提到了分層編譯，它使JIT能夠首先為一個方法生成優化最少的代碼，然後當該方法被證明是重要的時，用更多的優化重新編譯該方法。這允許代碼運行得更快，並且只有在運行時才升級有效的方法，從而實現更快的啟動時間。但是，分層編譯依賴於替換實現的能力，下次調用它時，將調用新的實現。但是長時間運行的方法呢?對於包含迴圈(或者，更具體地說，向後分支)的方法，分層編譯在預設情況下是禁用的，因為它們可能會運行很長時間，以至於無法及時使用替換。OSR允許方法在執行代碼時被更新，而它們是“在堆棧上”的;PR中包含的設計文檔中有很多細節(也與分層編譯有關，dotnet/runtime#1457改進了調用計數機制，分層編譯通過這種機制決定哪些方法應該重新編譯以及何時重新編譯)。您可以通過將COMPlus_TC_QuickJitForLoops和COMPlus_TC_OnStackReplacement環境變數設置為1來試驗OSR。另一個例子是，dotnet/runtime#1180 改進了try塊內代碼的生成代碼質量，使JIT能夠在寄存器中保存以前不能保存的值。您可以通過將COMPlus_EnableEHWriteThr環境變數設置為1來進行試驗。


還有一堆等待拉請求JIT尚未合併,但很可能在.NET 5發佈(除此之外，我預計還有更多在.NET 5發佈之前還沒有發佈的內容)。例如，dotnet/runtime#32716允許JIT替換一些分支比較，如a == 42 ?3: 2無分支實現，當硬體無法正確預測將採用哪個分支時，可以幫助提高性能。或dotnet/runtime#37226，它允許JIT採用像“hello”[0]這樣的模式並將其替換為h;雖然開發人員通常不編寫這樣的代碼，但在涉及內聯時，這可以提供幫助，通過將常量字元串傳遞給內聯的方法，並將其索引到常量位置(通常在長度檢查之後，由於dotnet/runtime#1378，長度檢查也可以成為常量)。或dotnet/runtime#1224，它改進了Bmi2的代碼生成。MultiplyNoFlags內在。或者dotnet/runtime#37836，它將轉換位操作。將PopCount轉換為一個內因，使JIT能夠識別何時使用常量參數調用它，並將整個操作替換為一個預先計算的常量。或dotnet/runtime#37254，它刪除使用const字元串時發出的空檢查。或者來自@damageboy的dotnet/runtime#32000 ，它優化了雙重否定。

Intrinsics

在.NET Core 3.0中，超過1000種新的硬體內置方法被添加並被JIT識別，從而使c#代碼能夠直接針對指令集，如SSE4和AVX2(docs)。然後，在核心庫中的一組api中使用了這些工具。但是，intrinsic僅限於x86/x64架構。在.NET 5中，我們投入了大量的精力來增加數千個組件，特別是針對ARM64，這要感謝眾多貢獻者，特別是來自Arm Holdings的@TamarChristinaArm。與對應的x86/x64一樣，這些內含物在核心庫功能中得到了很好的利用。例如，BitOperations.PopCount()方法之前被優化為使用x86 POPCNT內在的，對於.NET 5,  dotnet/runtime#35636 增強了它，使它也能夠使用ARM VCNT或等價的ARM64 CNT。類似地，dotnet/runtime#34486修改了位操作。LeadingZeroCount, TrailingZeroCount和Log2利用相應的instrincs。在更高的級別上，來自@Gnbrkm41的dotnet/runtime#33749增強了位數組中的多個方法，以使用ARM64內含物來配合之前添加的對SSE2和AVX2的支持。為了確保Vector api在ARM64上也能很好地執行，我們做了很多工作，比如dotnet/runtime#33749和dotnet/runtime#36156。


除ARM64之外，還進行了其他工作以向量化更多操作。 例如，@Gnbrkm41還提交了dotnet/runtime#31993，該文件利用x64上的ROUNDPS / ROUNDPD和ARM64上的FRINPT / FRINTM來改進為新Vector.Ceiling和Vector.Floor方法生成的代碼。 BitOperations（這是一種相對低級的類型，針對大多數操作以最合適的硬體內部函數的1：1包裝器的形式實現），不僅在@saucecontrol 的dotnet/runtime#35650中得到了改進，而且在Corelib中的使用也得到了改進 更有效率。


最後，JIT進行了大量的修改，以更好地處理硬體內部特性和向量化，比如dotnet/runtime#35421, dotnet/runtime#31834, dotnet/runtime#1280, dotnet/runtime#35857, dotnet/runtime#36267和 dotnet/runtime#35525。

Runtime helpers

GC和JIT代表了運行時的大部分，但是在運行時中這些組件之外仍然有相當一部分功能，並且這些功能也有類似的改進。
有趣的是，JIT不會為所有東西從頭生成代碼。JIT在很多地方調用了預先存在的 helpers函數，運行時提供這些 helpers，對這些 helpers的改進可以對程式產生有意義的影響。dotnet/runtime#23548 是一個很好的例子。在像System這樣的圖書館中。Linq，我們避免為協變介面添加額外的類型檢查，因為它們的開銷比普通介面高得多。本質上，dotnet/runtime#23548 (隨後在dotnet/runtime#34427中進行了調整)增加了一個緩存，這樣這些數據轉換的代價被平攤，最終總體上更快了。這從一個簡單的微基準測試中就可以明顯看出:

private List<string> _list = new List<string>();

// IReadOnlyCollection<out T> is covariant
[Benchmark] public bool IsIReadOnlyCollection() => IsIReadOnlyCollection(_list);
[MethodImpl(MethodImplOptions.NoInlining)]  private static bool IsIReadOnlyCollection(object o) => o is IReadOnlyCollection<int>;

另一組有影響的更改出現在dotnet/runtime#32270中(在dotnet/runtime#31957中支持JIT)。在過去，泛型方法只維護了幾個專用的字典槽，可以用於快速查找與泛型方法相關的類型;一旦這些槽用完，它就會回到一個較慢的查找表。這種限制不再存在，這些更改使快速查找槽可用於所有通用查找。

[Benchmark]
public void GenericDictionaries()
{
    for (int i = 0; i < 14; i++)
        GenericMethod<string>(i);
}

[MethodImpl(MethodImplOptions.NoInlining)]
private static object GenericMethod<T>(int level)
{
    switch (level)
    {
        case 0: return typeof(T);
        case 1: return typeof(List<T>);
        case 2: return typeof(List<List<T>>);
        case 3: return typeof(List<List<List<T>>>);
        case 4: return typeof(List<List<List<List<T>>>>);
        case 5: return typeof(List<List<List<List<List<T>>>>>);
        case 6: return typeof(List<List<List<List<List<List<T>>>>>>);
        case 7: return typeof(List<List<List<List<List<List<List<T>>>>>>>);
        case 8: return typeof(List<List<List<List<List<List<List<List<T>>>>>>>>);
        case 9: return typeof(List<List<List<List<List<List<List<List<List<T>>>>>>>>>);
        case 10: return typeof(List<List<List<List<List<List<List<List<List<List<T>>>>>>>>>>);
        case 11: return typeof(List<List<List<List<List<List<List<List<List<List<List<T>>>>>>>>>>>);
        case 12: return typeof(List<List<List<List<List<List<List<List<List<List<List<List<T>>>>>>>>>>>>);
        default: return typeof(List<List<List<List<List<List<List<List<List<List<List<List<List<T>>>>>>>>>>>>>);
    }
}

Text Processing

基於文本的處理是許多應用程式的基礎，並且在每個版本中都花費了大量的精力來改進基礎構建塊，其他所有內容都構建在這些基礎構建塊之上。這些變化從 helpers處理單個字元的微優化一直延伸到整個文本處理庫的大修。
系統。Char在NET 5中得到了一些不錯的改進。例如，dotnet/coreclr#26848提高了char的性能。通過調整實現來要求更少的指令和更少的分支。改善char。IsWhiteSpace隨後在一系列依賴於它的其他方法中出現，比如string.IsEmptyOrWhiteSpace和調整:

[Benchmark]
public int Trim() => " test ".AsSpan().Trim().Length;

Method	Runtime	Mean	Ratio	Code Size
Trim	.NET FW 4.8	21.694 ns	1.00	569 B
Trim	您的分享是我們最大的動力! -Advertisement- 更多相關文章 互聯網的寒冬下各大一線互聯網公司還在用SpringBoot這是為什麼？ 引言 現在各大技術社區 Spring Boot 的文章越來越多，Spring Boot 相關的圖文、視頻教程越來越多，使用 Spring Boot 的互聯網公司也越來越多； Java 程式員現在出去面試， Spring Boot 已經成了必問的內容。 一切都在證明，Spring Boot 已經成為了 ... 《c++入門經典》筆記11 《c++入門經典》筆記11 第十一章 開發高級指針 11.1在堆中創建對象 實際上，類就是對象的類型，對象也是一種變數，所以你可以在堆中創建int型變數，自然也就能創建自定義型變數。 Cat *pCat = new Cat; 這將調用預設構造函數（無參構造函數），每當在堆或棧中創建對象時，都將調用構 ... 《c++入門經典》筆記10 《c++入門經典》筆記10 第十章 創建指針 10.1理解指針及其用途 變數是可存儲一個值的對象：整型變數存儲一個數字，字元變數存儲一個字母，而指針是存儲記憶體地址的變數。 電腦記憶體是存儲變數值的地方。根據約定，電腦記憶體被劃分成按順序編號的記憶體單元，每個記憶體單元都有對應的地址。記憶體中，不管其類型是 ... 文件基本處理 一、文件基本處理1、什麼是文件 文件是操作系統提供給用戶/應用程式操作硬碟的一個虛擬單位ps:文件是操作系統的概念2、為何要用文件 存取硬碟必須使用文件ps:要永久保存數據就得用文件把數據放進硬碟3、如何用文件 f = open(文件路徑,打開模式) f.write(數據) f.close() 應用 ... Swoole 中協程的使用註意事項及協程中的異常捕獲 協程使用註意事項 協程內部禁止使用全局變數，以免發生數據錯亂； 協程使用 use 關鍵字引入外部變數到當前作用域禁止使用引用，以免發生數據錯亂； 不能使用類靜態變數 Class::$array / 全局變數 $_array / 全局對象屬性 $object->array / 其他超全局變數 $GLO ... PHP在使用move_uploaded_file函數移動文件時一直失敗 問題 ：最近在項目論壇中，因為要上傳自定義圖片，在做好上傳的前端處理後，在後臺使用move_uploaded_file函數，移動文件的時候，一直返回的是 false； ：因為對於這類新加的前端加後臺一起寫的功能，一般是先在本地建一個demo實現，然後在加入到項目中。就在這裡，居然出現一個問題，在前端 ... WPF MVVM 模式下的彈窗 WPF MVVM 模式下的彈窗，包括確認框和信息提示框，MVVM 模式的用戶控制項。 ... 水一貼，用任何一種語言導出oracle存儲過程（視圖）腳本 原理：依賴oracle user_source數據字典，將腳本select出來拼成字元串。 具體實現參考隔壁大佬：https://blog.csdn.net/xiaoqiaoluanwu/article/details/48733781 有了這個轉換的函數，剩下的就是用你習慣的語言把結構select ... 一周排行 -Advertisement- 移動開發（一）：使用.NET MAUI開發第一個安卓APP 移動開發（一）：使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說，近來想嘗試開發一款安卓APP，考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP，畢竟是使用Visual Studio開發工具，使用起來也比較的順手，結合微軟官方的教程進行了安卓 ... wpf ToggleButton選中效果和一個登錄界面 前言 QuestPDF 是一個開源 .NET 庫，用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫，它徹底改變了我們生成 PDF 文檔的方 ... 彈幕樹洞項目功能新增篇 項目地址 項目後端地址： https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址： ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址： http://tree ... 第27篇 sqlserver2022詳細安裝步驟 話不多說，直接開乾 一.下載 1.官方鏈接下載： https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe，運行開始下載SQL server； 二. ... .NET 開源高性能 MQTT 類庫 前言 隨著物聯網（IoT）技術的迅猛發展，MQTT（消息隊列遙測傳輸）協議憑藉其輕量級和高效性，已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫，為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ... Serilog文檔翻譯系列（六） - 可用的接收器、增強器、格式化輸出 Serilog支持多種接收器用於日誌存儲，增強器用於添加屬性，LogContext管理動態屬性，支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項，適用於不同需求。 ... 警惕 Visual Studio 屬性求值副作用導致邏輯不符合預期 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據，爬取信息時需要模擬瀏覽器行為，否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下： 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ... [使用目前最新版]HybridCLR6.9.0+YooAsset2.2.4實現純C# Unity熱更新方案 (一) 1.前言 什麼是熱更新 游戲或者軟體更新時，無需重新下載客戶端進行安裝，而是在應用程式啟動的情況下，在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR，Xlua，ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles，Addressable， ... 在 ASP.NET Core Web API 中使用操作篩選器統一處理通用操作 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺，其實像阿裡雲，騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後，它會送 ... 第28篇 如何.net中實現高效可靠數據同步api 通過以下方式可以高效，並保證數據同步的可靠性 1.API設計 使用RESTful設計，確保API端點明確，並使用適當的HTTP方法（如POST用於創建，PUT用於更新）。 設計清晰的請求和響應模型，以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證，確保接收到的數據符合預期格 ... 所有分類 NET技術 編程語言 軟件設計 WEB前端 手機開發 數據庫技術 操作系統