是什么优化让 .NET Core 性能飙升？
.NET Core（開放源代碼，跨平臺，x-copy可部署等）有許多令人興奮的方面，其中最值得稱贊的就是其性能了。
感謝所有社區開發人員對.NET Core做出的貢獻，其中的許多改進也將在接下來的幾個版本中引入.NET Framework。
本文主要介紹.NET Core中的一些性能改進，特別是.NET Core 2.0中的，重點介紹各個核心庫的一些示例。
?
集合
集合是任何應用程序的基石，同時.NET庫中也有大量集合。.NET庫中的一些改進是為了消除開銷，例如簡化操作以便更好的實現內聯，減少指令數量等。例如，下面的這個使用Q<T>的例子：
using?System;using?System.Diagnostics;using?System.Collections.Generic;public?class?Test {????public?static?void?Main(){????????while?(true){????????????var?q?=?new?Queue<int>();????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?100_000_000;?i++){q.Enqueue(i);q.Dequeue();}Console.WriteLine(sw.Elapsed);}} }PR?dotnet/corefx #2515移除了這些操作中相對復雜的模數運算，在個人計算機，以上代碼在.NET 4.7上產生如下輸出：
00：00：00.9392595? 00：00：00.9390453? 00：00：00.9455784? 00：00：00.9508294? 00：00：01.0107745而使用.NET Core 2.0則會產生如下輸出：
00：00：00.5514887? 00：00：00.5662477? 00：00：00.5627481? 00：00：00.5685286? 00：00：00.5262378由于這是掛鐘時間所節省的，較小的值計算的更快，這也表明吞吐量增加了約2倍！
在其他情況下，通過更改操作算法的復雜性，可以更快地進行操作。編寫軟件時，最初編寫的一個簡單實現，雖然是正確的，但是這樣實現往往不能表現出最佳的性能，直到特定的場景出現時，才考慮如何提高性能。例如，SortedSet <T>的ctor最初以相對簡單的方式編寫，由于使用O（N ^ 2）算法來處理重復項，因此不能很好地處理復雜性。該算法在PRnetnet / corefx＃1955中的.NET Core中得到修復。以下簡短的程序說明了修復的區別：
using?System;using?System.Diagnostics;using?System.Collections.Generic;using?System.Linq;public?class?Test {????public?static?void?Main(){????????var?sw?=?Stopwatch.StartNew();????????var?ss?=?new?SortedSet<int>(Enumerable.Repeat(42,?400_000));Console.WriteLine(sw.Elapsed);} }在個人電腦的.NET Framework上，這段代碼需要大約7.7秒執行完成。在.NET Core 2.0上，減少到大約0.013s（改進改變了算法的復雜性，集合越大，節省的時間越多）。
或者在SortedSet <T>上考慮這個例子：
public?class?Test {????static?int?s_result;????public?static?void?Main(){????????while?(true){????????????var?s?=?new?SortedSet<int>();????????????for?(int?n?=?0;?n?<?100_000;?n++){s.Add(n);}????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?10_000_000;?i++){s_result?=?s.Min;}Console.WriteLine(sw.Elapsed);}} }.NET 4.7中Min和Max的實現遍布SortedSet <T>的整個樹，但是只需要找到最小或最大值即可，因為實現可以只遍歷相關的節點。PR?dotnet / corefx＃11968修復了.NET Core實現。在.NET 4.7中，此示例生成如下結果：
00：00：01.1427246 00：00：01.1295220? 00：00：01.1350696? 00：00：01.1502784? 00：00：01.1677880而在.NET Core 2.0中，我們得到如下結果：
00：00：00.0861391? 00：00：00.0861183? 00：00：00.0866616? 00：00：00.0848434? 00：00：00.0860198顯示出相當大的時間下降和吞吐量的增加。
即使像List <T>這樣的主工作核心也有改進的空間。考慮下面的例子：
using?System;using?System.Diagnostics;using?System.Collections.Generic;public?class?Test {????public?static?void?Main(){????????while?(true){????????????var?l?=?new?List<int>();????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?100_000_000;?i++){l.Add(i);l.RemoveAt(0);}Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，會得到的結果如下：
00：00：00.4434135? 00：00：00.4394329? 00：00：00.4496867? 00：00：00.4496383? 00：00：00.4515505和.NET Core 2.0，得到：
00：00：00.3213094? 00：00：00.3211772? 00：00：00.3179631? 00：00：00.3198449? 00：00：00.3164009可以肯定的是，在0.3秒內可以實現1億次這樣的添加并從列表中刪除的操作，這表明操作開始并不慢。但是，通過執行一個應用程序，列表通常會添加到很多，同時也節省了總時間消耗。
這些類型的集合改進擴展不僅僅是System.Collections.Generic命名空間;?System.Collections.Concurrent也有很多改進。事實上，.NET Core 2.0上的ConcurrentQueue <T>和ConcurrentBag <T>完全重寫了。下面看看一個基本的例子，使用ConcurrentQueue <T>但沒有任何并發，例子中使用ConcurrentQueue <T>代替了Queue<T>：
using?System;using?System.Diagnostics;using?System.Collections.Concurrent;public?class?Test {????public?static?void?Main(){????????while?(true){????????????var?q?=?new?ConcurrentQueue<int>();????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?100_000_000;?i++){q.Enqueue(i);q.TryDequeue(out?int?_);}Console.WriteLine(sw.Elapsed);}} }在個人電腦上，.NET 4.7產生的輸出如下：
00：00：02.6485174 00：00：02.6144919? 00：00：02.6699958? 00：00：02.6441047? 00：00：02.6255135顯然，.NET 4.7上的ConcurrentQueue <T>示例比.NET 4.7中的Queue <T>版本慢，因為ConcurrentQueue <T>需要采用同步來確保是否安全使用。但是，更有趣的比較是當在.NET Core 2.0上運行相同的代碼時會發生什么：
00：00：01.7700190? 00：00：01.8324078? 00：00：01.7552966? 00：00：01.7518632? 00：00：01.7560811這表明當將.NET Core 2.0切換到30％時，ConcurrentQueue <T>的吞吐量沒有任何并發性提高。但是實施中的變化提高了序列化的吞吐量，甚至更多地減少了使用隊列的生產和消耗之間的同步，這可能對吞吐量有更明顯的影響。請考慮以下代碼：
using?System;using?System.Diagnostics;using?System.Collections.Concurrent;using?System.Threading.Tasks;public?class?Test {????public?static?void?Main(){????????while?(true){????????????const?int?Items?=?100_000_000;????????????var?q?=?new?ConcurrentQueue<int>();????????????var?sw?=?Stopwatch.StartNew();Task?consumer?=?Task.Run(()?=>{????????????????int?total?=?0;????????????????while?(total?<?Items)?if?(q.TryDequeue(out?int?_))?total++;});????????????for?(int?i?=?0;?i?<?Items;?i++)?q.Enqueue(i);consumer.Wait();Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，個人計算機輸出如下結果：
00：00：06.1366044 00：00：05.7169339? 00：00：06.3870274? 00：00：05.5487718? 00：00：06.6069291而使用.NET Core 2.0，會得到以下結果：
00：00：01.2052460? 00：00：01.5269184? 00：00：01.4638793? 00：00：01.4963922? 00：00：01.4927520這是一個3.5倍的吞吐量的增長。不但CPU效率提高了，?而且內存分配也大大減少。下面的例子主要觀察GC集合的數量，而不是掛鐘時間：
using?System;using?System.Diagnostics;using?System.Collections.Concurrent;public?class?Test {????public?static?void?Main(){????????while?(true){????????????var?q?=?new?ConcurrentQueue<int>();????????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);????????????for?(int?i?=?0;?i?<?100_000_000;?i++){q.Enqueue(i);q.TryDequeue(out?int?_);}Console.WriteLine($"Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");}} }在.NET 4.7中，得到以下輸出：
Gen0?=?162?Gen1?=?80?Gen2?=?0?Gen0?=?162?Gen1?=?81?Gen2?=?0?Gen0?=?162?Gen1?=?81?Gen2?=?0?Gen0?=?162?Gen1?=?81?Gen2?=?0?Gen0?=?162?Gen1?=?81?Gen2?=?0而使用.NET Core 2.0，會得到如下輸出：
Gen0?=?0?Gen1?=?0?Gen2?=?0?Gen0?=?0?Gen1?=?0?Gen2?=?0?Gen0?=?0?Gen1?=?0?Gen2?=?0?Gen0?=?0?Gen1?=?0?Gen2?=?0?Gen0?=?0?Gen1?=?0?Gen2?=?0.NET 4.7中的實現使用了固定大小的數組鏈表，一旦固定數量的元素被添加到每個數組中，就會被丟棄，?這有助于簡化實現，但也會導致生成大量垃圾。在.NET Core 2.0中，新的實現仍然使用鏈接在一起的鏈接列表，但是隨著新的片段的添加，這些片段的大小會增加，更重要的是使用循環緩沖區，只有在前一個片段完全結束時，新片段才會增加。這種分配的減少可能對應用程序的整體性能產生相當大的影響。
ConcurrentBag <T>也有類似改進。ConcurrentBag <T>維護thread-local work-stealing隊列，使得添加到的每個線程都有自己的隊列。在.NET 4.7中，這些隊列被實現為每個元素占據一個節點的鏈接列表，這意味著對該包的任何添加都會導致分配。在.NET Core 2.0中，這些隊列是數組，這意味著除了增加陣列所涉及的均攤成本之外，增加的還是無需配置的。以下可以看出：
using?System;using?System.Diagnostics;using?System.Collections.Concurrent;public?class?Test {????public?static?void?Main(){????????while?(true){????????????var?q?=?new?ConcurrentBag<int>()?{?1,?2?};????????????var?sw?=?new?Stopwatch();????????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);sw.Start();????????????for?(int?i?=?0;?i?<?100_000_000;?i++){q.Add(i);q.TryTake(out?int?_);}sw.Stop();Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");}} }在.NET 4.7中，個人計算機上產生以下輸出：
Elapsed=00:00:06.5672723?Gen0=953?Gen1=0?Gen2=0Elapsed=00:00:06.4829793?Gen0=954?Gen1=1?Gen2=0Elapsed=00:00:06.9008532?Gen0=954?Gen1=0?Gen2=0Elapsed=00:00:06.6485667?Gen0=953?Gen1=1?Gen2=0Elapsed=00:00:06.4671746?Gen0=954?Gen1=1?Gen2=0而使用.NET Core 2.0，會得到：
Elapsed=00:00:04.3377355?Gen0=0?Gen1=0?Gen2=0Elapsed=00:00:04.2892791?Gen0=0?Gen1=0?Gen2=0Elapsed=00:00:04.3101593?Gen0=0?Gen1=0?Gen2=0Elapsed=00:00:04.2652497?Gen0=0?Gen1=0?Gen2=0Elapsed=00:00:04.2808077?Gen0=0?Gen1=0?Gen2=0吞吐量提高了約30％，并且分配和完成的垃圾收集量減少了。
?
LINQ
在應用程序代碼中，集合通常與語言集成查詢（LINQ）緊密相連，該查詢已經有了更多的改進。LINQ中的許多運算符已經完全重寫為.NET Core，以便減少分配的數量和大小，降低算法復雜度，并且消除不必要的工作。
例如，Enumerable.Concat方法用于創建一個單一的IEnumerable <T>，它首先產生first域可枚舉的所有元素，然后再生成second域所有的元素。它在.NET 4.7中的實現是簡單易懂的，下面的代碼正好反映了這種行為表述：
static?IEnumerable<TSource>?ConcatIterator<TSource>(IEnumerable<TSource>?first,?IEnumerable<TSource>?second)?{????foreach?(TSource?element?in?first)?yield?return?element;????foreach?(TSource?element?in?second)?yield?return?element; }當兩個序列是簡單的枚舉，如C＃中的迭代器生成的，這種過程會執行的很好。但是如果應用程序代碼具有如下代碼呢？
first.Concat(second.Concat(third.Concat(fourth)));每次我們從迭代器中退出時，則會返回到枚舉器的MoveNext方法。這意味著如果你從另一個迭代器中枚舉產生一個元素，則會返回兩個MoveNext方法，并移動到下一個需要調用這兩個MoveNext方法的元素。你調用的枚舉器越多，操作所需的時間越長，特別是這些操作中的每一個都涉及多個接口調用（MoveNext和Current）。這意味著連接多個枚舉會以指數方式增長，而不是呈線性增長。PR?dotnet / corefx＃6131修正了這個問題，在下面的例子中，區別是顯而易見的：
using?System;using?System.Collections.Generic;using?System.Diagnostics;using?System.Linq;public?class?Test {????public?static?void?Main(){IEnumerable<int>?zeroToTen?=?Enumerable.Range(0,?10);IEnumerable<int>?result?=?zeroToTen;????????for?(int?i?=?0;?i?<?10_000;?i++){result?=?result.Concat(zeroToTen);}????????var?sw?=?Stopwatch.StartNew();????????foreach?(int?i?in?result)?{?}Console.WriteLine(sw.Elapsed);} }在個人計算機上，.NET 4.7需要大約4.12秒。但在.NET Core 2.0中，這只需要約0.14秒，提高了30倍。
通過消除多個運算器同時使用時的消耗，運算器也得到了大大的提升。例如下面的例子：
using?System;using?System.Collections.Generic;using?System.Diagnostics;using?System.Linq;public?class?Test {????public?static?void?Main(){IEnumerable<int>?tenMillionToZero?=?Enumerable.Range(0,?10_000_000).Reverse();????????while?(true){????????????var?sw?=?Stopwatch.StartNew();????????????int?fifth?=?tenMillionToZero.OrderBy(i?=>?i).Skip(4).First();Console.WriteLine(sw.Elapsed);}} }在這里，我們創建一個可以從10,000,000下降到0的數字，然后再等待一會來排序它們上升，跳過排序結果中的前4個元素，并抓住第五個。在個人計算機上的NET 4.7中得到如下輸出：
00：00：01.3879042? 00：00：01.3438509? 00：00：01.4141820? 00：00：01.4248908? 00：00：01.3548279而使用.NET Core 2.0，會得到如下輸出：
00：00：00.1776617? 00：00：00.1787467? 00：00：00.1754809? 00：00：00.1765863? 00：00：00.1735489這是一個巨大的改進（8x），避免了大部分的開銷。
類似地，來自justinvp的?PR?dotnet / corefx＃3429對常用的ToList方法添加了優化，為已知長度的源，提供了優化的路徑，并且通過像Select這樣的操作器來管理。在以下簡單測試中，這種影響是顯而易見的：
using?System;using?System.Collections.Generic;using?System.Diagnostics;using?System.Linq;public?class?Test {????public?static?void?Main(){IEnumerable<int>?tenMillionToZero?=?Enumerable.Range(0,?10_000_000).Reverse();????????while?(true){????????????var?sw?=?Stopwatch.StartNew();????????????int?fifth?=?tenMillionToZero.OrderBy(i?=>?i).Skip(4).First();Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，會得到如下結果：
00：00：00.1308687? 00：00：00.1228546? 00：00：00.1268445? 00：00：00.1247647? 00：00：00.1503511而在.NET Core 2.0中，得到如下結果：
00：00：00.0386857? 00：00：00.0337234? 00：00：00.0346344? 00：00：00.0345419? 00：00：00.0355355顯示吞吐量增加約4倍。
在其他情況下，性能優勢來自于簡化實施，以避免開銷，例如減少分配，避免委托分配，避免接口調用，最小化字段讀取和寫入，避免拷貝等。例如，jamesqo為PR?dotnet / corefx＃11208做出的貢獻，大大地減少了Enumerable.ToArray涉及的開銷。請看下面的例子：
using?System;using?System.Collections.Generic;using?System.Diagnostics;using?System.Linq;public?class?Test {????public?static?void?Main(){IEnumerable<int>?zeroToTenMillion?=?Enumerable.Range(0,?10_000_000).ToArray();????????while?(true){????????????var?sw?=?Stopwatch.StartNew();zeroToTenMillion.Select(i?=>?i).ToList();Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，會得到如下的結果：
Elapsed=00:00:01.0548794?Gen0=2?Gen1=2?Gen2=2Elapsed=00:00:01.1147146?Gen0=2?Gen1=2?Gen2=2Elapsed=00:00:01.0709146?Gen0=2?Gen1=2?Gen2=2Elapsed=00:00:01.0706030?Gen0=2?Gen1=2?Gen2=2Elapsed=00:00:01.0620943?Gen0=2?Gen1=2?Gen2=2而.NET Core 2.0的結果如下：
Elapsed=00:00:00.1716550?Gen0=1?Gen1=1?Gen2=1Elapsed=00:00:00.1720829?Gen0=1?Gen1=1?Gen2=1Elapsed=00:00:00.1717145?Gen0=1?Gen1=1?Gen2=1Elapsed=00:00:00.1713335?Gen0=1?Gen1=1?Gen2=1Elapsed=00:00:00.1705285?Gen0=1?Gen1=1?Gen2=1這個例子中提高了6倍，但是垃圾收集卻只有一半。
LINQ有一百多個運算器，本文只提到了幾個，其它的很多也都有所改進。
?
壓縮
前面所展示的集合和LINQ的例子都是處理內存中的數據，當然還有許多其他形式的數據處理，包括大量CPU計算和邏輯判斷，這些運算也在得到提升。
一個關鍵的例子是壓縮，例如使用DeflateStream，性能方面也有一些重大的性能改進。例如，在.NET 4.7中，zlib（本地壓縮庫）用于壓縮數據，但是相對未優化的托管實現了用于解壓縮的數據;?PR?dotnet / corefx＃2906添加了.NET Core支持，以便使用zlib進行解壓縮。來自bjjones的?PR?dotnet / corefx＃5674使用英特爾生產的zlib這個更優化的版本。這些結合產生了非常棒的效果。下面的例子，創建一個大量的數據：
using?System;using?System.IO;using?System.IO.Compression;using?System.Diagnostics;public?class?Test {????public?static?void?Main(){????????//?Create?some?fairly?compressible?databyte[]?raw?=?new?byte[100?*?1024?*?1024];????????for?(int?i?=?0;?i?<?raw.Length;?i++)?raw[i]?=?(byte)i;????????var?sw?=?Stopwatch.StartNew();????????//?Compress?itvar?compressed?=?new?MemoryStream();????????using?(DeflateStream?ds?=?new?DeflateStream(compressed,?CompressionMode.Compress,?true)){ds.Write(raw,?0,?raw.Length);}compressed.Position?=?0;????????//?Decompress?itvar?decompressed?=?new?MemoryStream();????????using?(DeflateStream?ds?=?new?DeflateStream(compressed,?CompressionMode.Decompress)){ds.CopyTo(decompressed);}decompressed.Position?=?0;Console.WriteLine(sw.Elapsed);} }在.NET 4.7中，這一個壓縮/解壓縮操作，會得到如下結果：
00：00：00.7977190而使用.NET Core 2.0，會得到如下結果：
00：00：00.1926701?
加密
.NET應用程序中另一個常見的計算源是使用加密操作，在這方面.NET Core也有改進。例如，在.NET 4.7中，SHA256.Create返回在管理代碼中實現的SHA256類型，而管理代碼可以運行得非常快，但是對于運算量非常大的計算，這仍然難以與原始吞吐量和編譯器優化競爭。相反，對于.NET Core 2.0，SHA256.Create返回基于底層操作系統的實現，例如在Windows上使用CNG或在Unix上使用OpenSSL。從下面這個簡單的例子可以看出，它散列著一個100MB的字節數組：
using?System;using?System.Diagnostics;using?System.Security.Cryptography;public?class?Test {????public?static?void?Main(){????????byte[]?raw?=?new?byte[100?*?1024?*?1024];????????for?(int?i?=?0;?i?<?raw.Length;?i++)?raw[i]?=?(byte)i;????????using?(var?sha?=?SHA256.Create()){????????????var?sw?=?Stopwatch.StartNew();sha.ComputeHash(raw);Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，會得到：
00：00：00.7576808而使用.NET Core 2.0，會得到：
00：00：00.4032290零代碼更改的一個很好提升。
?
數學運算
數學運算也是一個很大的計算量，特別是處理大量數據時。通過像dotnet / corefx＃2182這樣的PR?，axelheer對BigInteger的各種操作做了一些實質的改進。請考慮以下示例：
using?System;using?System.Diagnostics;using?System.Numerics;public?class?Test {????public?static?void?Main(){????????var?rand?=?new?Random(42);BigInteger?a?=?Create(rand,?8192);BigInteger?b?=?Create(rand,?8192);BigInteger?c?=?Create(rand,?8192);????????var?sw?=?Stopwatch.StartNew();BigInteger.ModPow(a,?b,?c);Console.WriteLine(sw.Elapsed);}????private?static?BigInteger?Create(Random?rand,?int?bits){????????var?value?=?new?byte[(bits?+?7)?/?8?+?1];rand.NextBytes(value);value[value.Length?-?1]?=?0;????????return?new?BigInteger(value);} }在.NET 4.7中，會得到以下輸出結果：
00：00：05.6024158.NET Core 2.0上的相同代碼會得到輸出結果如下：
00：00：01.2707089這是開發人員只關注.NET的某個特定領域的一個很好的例子，開發人員使得這種改進更好的滿足了自己的需求，同時也滿足了可能會用到這方面功能的其他開發人員的需求。
一些核心的整型類型的數學運算也得到了改進。例如：
using?System;using?System.Diagnostics;public?class?Test {????private?static?long?a?=?99,?b?=?10,?div,?rem;????public?static?void?Main(){????????var?sw?=?Stopwatch.StartNew();????????for?(int?i?=?0;?i?<?100_000_000;?i++){div?=?Math.DivRem(a,?b,?out?rem);}Console.WriteLine(sw.Elapsed);} }PR?dotnet / coreclr＃8125用更快的實現取代了DivRem，在.NET 4.7中會得到的如下結果：
00：00：01.4143100并在.NET Core 2.0上得到如下結果：
00：00：00.7469733吞吐量提高約2倍。
?
序列化
二進制序列化是.NET的另一個領域。BinaryFormatter最初并不是.NET Core中的一個組件，但是它包含在.NET Core 2.0中。該組件在性能方面有比較巧妙的修復。例如，PR?dotnet / corefx＃17949是一種單行修復，可以增加允許增長的最大大小的特定數組，但是這一變化可能對吞吐量產生重大影響，通過O（N）算法比以前的O（N ^ 2）算法要話費更長的操作時間。以下代碼示例，明顯的展示了這一點：
using?System;using?System.Collections.Generic;using?System.Diagnostics;using?System.IO;using?System.Runtime.Serialization.Formatters.Binary;class?Test {????static?void?Main(){????????var?books?=?new?List<Book>();????????for?(int?i?=?0;?i?<?1_000_000;?i++){????????????string?id?=?i.ToString();books.Add(new?Book?{?Name?=?id,?Id?=?id?});}????????var?formatter?=?new?BinaryFormatter();????????var?mem?=?new?MemoryStream();formatter.Serialize(mem,?books);mem.Position?=?0;????????var?sw?=?Stopwatch.StartNew();formatter.Deserialize(mem);sw.Stop();Console.WriteLine(sw.Elapsed.TotalSeconds);}[Serializable]????private?class?Book{????????public?string?Name;????????public?string?Id;} }在.NET 4.7中，代碼輸出如下結果：
76.677144而在.NET Core 2.0中，會輸出如下結果：
6.4044694在這種情況下顯示出了12倍的吞吐量提高。換句話說，它能夠更有效地處理巨大的序列化輸入。
?
文字處理
.NET應用程序中另一種很常見的計算形式就是處理文本，文字處理在堆棧的各個層次上都有大量的改進。
對于正則表達式，通常用于驗證和解析輸入文本中的數據。以下是使用Regex.IsMatch重復匹配電話號碼的示例：
using?System;using?System.Diagnostics;using?System.Text.RegularExpressions;public?class?Test {????public?static?void?Main(){????????var?sw?=?new?Stopwatch();????????int?gen0?=?GC.CollectionCount(0);sw.Start();????????for?(int?i?=?0;?i?<?10_000_000;?i++){Regex.IsMatch("555-867-5309",?@"^\d{3}-\d{3}-\d{4}$");}Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}");} }在個人計算機上，.NET 4.7會得到的如下結果：
Elapsed=00:00:05.4367262?Gen0=820?Gen1=0?Gen2=0而使用.NET Core 2.0會得到如下結果：
Elapsed=00:00:04.0231373?Gen0=248由于PR?dotnet / corefx＃231的變化很小，這些修改有助于緩存一部分數據，因此吞吐量提高了25％，分配/垃圾收集減少了70％。
文本處理的另一個例子是各種形式的編碼和解碼，例如通過WebUtility.UrlDecode進行URL解碼。在這種解碼方法中，通常情況下輸入不需要任何解碼，但是如果輸入經過了×××，則輸入仍然可以通過。感謝來自hughbe的?PR?dotnet / corefx＃7671，這種情況已經被優化了。例如下面這段程序：
using?System;using?System.Diagnostics;using?System.Net;public?class?Test {????public?static?void?Main(){????????var?sw?=?new?Stopwatch();????????int?gen0?=?GC.CollectionCount(0);sw.Start();????????for?(int?i?=?0;?i?<?10_000_000;?i++){WebUtility.UrlDecode("abcdefghijklmnopqrstuvwxyz");}Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}");} }在.NET 4.7中，會得到以下輸出：
Elapsed=00:00:01.6742583?Gen0=648而在.NET Core 2.0中，輸出如下：
Elapsed=00:00:01.2255288?Gen0=133其他形式的編碼和解碼也得到了改進。例如，dotnet / coreclr＃10124優化了使用一些內置Encoding?-derived類型的循環。例如下面的示例：
using?System;using?System.Diagnostics;using?System.Linq;using?System.Text;public?class?Test {????public?static?void?Main(){????????string?s?=?new?string(Enumerable.Range(0,?1024).Select(i?=>?(char)('a'?+?i)).ToArray());????????while?(true){????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?1_000_000;?i++){????????????????byte[]?data?=?Encoding.UTF8.GetBytes(s);}Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中得到以下輸出，如：
00：00：02.4028829? 00：00：02.3743152? 00：00：02.3401392? 00：00：02.4024785? 00：00：02.3550876而.NET Core 2.0等到如下輸出：
00：00：01.6133550? 00：00：01.5915718? 00：00：01.5759625? 00：00：01.6070851? 00：00：01.6070767這些改進也適用于字符串和其它類型之間轉換，例如.NET中生成Parse和ToString方法。使用枚舉來表示各種狀態是相當普遍的，例如使用Enum.Parse將字符串解析為相應的枚舉。PR?dotnet / coreclr＃2933改善了這一點。請查看以下的代碼：
using?System;using?System.Diagnostics;public?class?Test {????public?static?void?Main(){????????while?(true){????????????var?sw?=?new?Stopwatch();????????????int?gen0?=?GC.CollectionCount(0);sw.Start();????????????for?(int?i?=?0;?i?<?2_000_000;?i++){Enum.Parse(typeof(Colors),?"Red,?Orange,?Yellow,?Green,?Blue");}Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}");}}[Flags]????private?enum?Colors{Red?=?0x1,Orange?=?0x2,Yellow?=?0x4,Green?=?0x8,Blue?=?0x10} }在.NET 4.7中，會得到的以下結果：
Elapsed=00:00:00.9529354?Gen0=293Elapsed=00:00:00.9422960?Gen0=294Elapsed=00:00:00.9419024?Gen0=294Elapsed=00:00:00.9417014?Gen0=294Elapsed=00:00:00.9514724?Gen0=293在.NET Core 2.0上，會得到以下結果：
Elapsed=00:00:00.6448327?Gen0=11Elapsed=00:00:00.6438907?Gen0=11Elapsed=00:00:00.6285656?Gen0=12Elapsed=00:00:00.6286561?Gen0=11Elapsed=00:00:00.6294286?Gen0=12不但吞吐量提高了約33％，而且分配和相關垃圾收集也減少了約25倍。
當然，在.NET應用程序中需要進行大量的自定義文本處理，除了使用像Regex?/?Encoding這樣的內置類型和Parse和ToString這樣的內置操作之外，文本操作通常都是直接構建在字符串之上，并且大量的改進已經引入到了操作on?String之上。
例如，String.IndexOf很擅長于查找字符串中的字符。IndexOf在bnetyersmyth的dotnet / coreclr＃5327中得到改進，他們為String實現了一系列的性能改進。正如下面的例子：
using?System;using?System.Diagnostics;public?class?Test {????public?static?void?Main(){????????var?dt?=?DateTime.Now;????????while?(true){????????????var?sw?=?new?Stopwatch();????????????int?gen0?=?GC.CollectionCount(0);sw.Start();????????????for?(int?i?=?0;?i?<?2_000_000;?i++){dt.ToString("o");dt.ToString("r");}Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}");}} }在.NET 4.7上，會得到如下結果：
00：00：05.9718129? 00：00：05.9199793? 00：00：06.0203108? 00：00：05.9458049? 00：00：05.9622262而在.NET Core 2.0中，會得到如下結果：
00：00：03.1283763? 00：00：03.0925150? 00：00：02.9778923? 00：00：03.0782851吞吐量提高約2倍。
下面是比較字符串部分。這是一個使用String.StartsWith和序數比較的例子：?
using?System;using?System.Diagnostics;using?System.Linq;public?class?Test {????public?static?void?Main(){????????string?s?=?string.Concat(Enumerable.Repeat("a",?100))?+?"b";????????while?(true){????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?100_000_000;?i++){s.IndexOf('b');}Console.WriteLine(sw.Elapsed);}} }在.NET 4.7上會得到如下結果：
00：00：01.3097317? 00：00：01.3072381? 00：00：01.3045015? 00：00：01.3068244? 00：00：01.3210207.NET Core 2.0會得到如下結果：
00：00：00.6239002? 00：00：00.6150021? 00：00：00.6147173? 00：00：00.6129136? 00：00：00.6099822對String的改進，也讓我們看到對于其它方面進行更多改進的可能性，這是非常有趣的。
?
文件系統
到目前為止，本文一直專注于內存中操縱數據的各種改進。但是.NET Core的許多更改都是關于I / O的。
下面從文件開始介紹。這是一個從文件中異步讀取所有數據并將其寫入另一個文件的示例：
using?System;using?System.Diagnostics;using?System.IO;using?System.Threading.Tasks;class?Test {????static?void?Main()?=>?MainAsync().GetAwaiter().GetResult();????static?async?Task?MainAsync(){????????string?inputPath?=?Path.GetTempFileName(),?outputPath?=?Path.GetTempFileName();????????byte[]?data?=?new?byte[50_000_000];????????new?Random().NextBytes(data);File.WriteAllBytes(inputPath,?data);????????var?sw?=?new?Stopwatch();????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);sw.Start();????????for?(int?i?=?0;?i?<?100;?i++){????????????using?(var?input?=?new?FileStream(inputPath,?FileMode.Open,?FileAccess.Read,?FileShare.Read,?0x1000,?useAsync:?true))????????????using?(var?output?=?new?FileStream(outputPath,?FileMode.Create,?FileAccess.ReadWrite,?FileShare.None,?0x1000,?useAsync:?true)){????????????????await?input.CopyToAsync(output);}}Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");} }?
FileStream中的開銷也在進一步減少，例如DOTNET / corefx＃11569增加了一個專門的CopyToAsync實現，dotnet/ corefx＃2929也改進了異步寫入的處理，.NET 4.7會得到如下結果：
Elapsed=00:00:09.4070345?Gen0=14?Gen1=7?Gen2=1.NET Core 2.0會得到如下結果：
Elapsed=00:00:06.4286604?Gen0=4?Gen1=1?Gen2=1?
網絡
網絡是值得關注的部分，這部分也將取得很大的改進。目前正在付出很大的努力來優化和調整低等級的網絡堆棧，以便高效地構建更高級別的組件。
這種改變帶來的一個很大的影響是PR?dotnet / corefx＃15141。SocketAsyncEventArgs是Socket上大量異步操作的核心，它支持同步完成模型，因此異步操作實際完成了同步操作，這樣避免了異步操作的分配消耗。但是，.NET 4.7中的同步操作運算是失敗的，?PR修復了上述的實現問題，允許在socket上進行所有異步操作的同步完成。這樣的提升在以下代碼中變現的非常明顯：
using?System;using?System.Diagnostics;using?System.Net;using?System.Net.Sockets;using?System.Threading;using?System.Threading.Tasks;class?Test {????static?void?Main(){????????using?(Socket?listener?=?new?Socket(AddressFamily.InterNetwork,?SocketType.Stream,?ProtocolType.Tcp))????????using?(Socket?client?=?new?Socket(AddressFamily.InterNetwork,?SocketType.Stream,?ProtocolType.Tcp)){listener.Bind(new?IPEndPoint(IPAddress.Loopback,?0));listener.Listen(1);Task?connectTask?=?Task.Run(()?=>?client.Connect(listener.LocalEndPoint));????????????using?(Socket?server?=?listener.Accept()){connectTask.Wait();????????????????using?(var?clientAre?=?new?AutoResetEvent(false))????????????????using?(var?clientSaea?=?new?SocketAsyncEventArgs())????????????????using?(var?serverAre?=?new?AutoResetEvent(false))????????????????using?(var?serverSaea?=?new?SocketAsyncEventArgs()){????????????????????byte[]?sendBuffer?=?new?byte[1000];clientSaea.SetBuffer(sendBuffer,?0,?sendBuffer.Length);clientSaea.Completed?+=?delegate?{?clientAre.Set();?};????????????????????byte[]?receiveBuffer?=?new?byte[1000];serverSaea.SetBuffer(receiveBuffer,?0,?receiveBuffer.Length);serverSaea.Completed?+=?delegate?{?serverAre.Set();?};????????????????????var?sw?=?new?Stopwatch();????????????????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);sw.Start();????????????????????for?(int?i?=?0;?i?<?1_000_000;?i++){????????????????????????if?(client.SendAsync(clientSaea))?clientAre.WaitOne();????????????????????????if?(clientSaea.SocketError?!=?SocketError.Success)?throw?new?SocketException((int)clientSaea.SocketError);????????????????????????if?(server.ReceiveAsync(serverSaea))?serverAre.WaitOne();????????????????????????if?(serverSaea.SocketError?!=?SocketError.Success)?throw?new?SocketException((int)clientSaea.SocketError);}Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");}}}} }該程序創建兩個連接的socket，然后向socket寫入1000次，并且在案例中使用異步方法接收，但絕大多數操作將同步完成。在.NET 4.7中會得到如下結果：
Elapsed=00:00:20.5272910?Gen0=42?Gen1=2?Gen2=0在.NET Core 2.0中，大多數操作能夠同步完成，得到如下結果：
Elapsed=00:00:05.6197060?Gen0=0?Gen1=0?Gen2=0不僅僅是直接使用socket來實現組件的這種改進，而且還通過更高級別的組件來間接使用socket，其他PR的結果是更高級別組件（如NetworkStream）的額外性能提升。例如，PR?dotnet / corefx＃16502在SocketAsyncEventArgs上重新實現了基于Socket的SendAsync和ReceiveAsync操作，并且允許它們在NetworkStream中使用。Read?/?WriteAsync和PR?dotnet / corefx＃12664添加了一個專門的CopyToAsync重寫，以便更有效地從NetworkStream讀取數據并將其復制到其他流中。這些變化對NetworkStream吞吐量和分配有非常大的影響。看看下面這個例子：
using?System;using?System.Diagnostics;using?System.IO;using?System.Net;using?System.Net.Sockets;using?System.Threading;using?System.Threading.Tasks;class?Test {????static?void?Main()?=>?MainAsync().GetAwaiter().GetResult();????static?async?Task?MainAsync(){????????using?(Socket?listener?=?new?Socket(AddressFamily.InterNetwork,?SocketType.Stream,?ProtocolType.Tcp))????????using?(Socket?client?=?new?Socket(AddressFamily.InterNetwork,?SocketType.Stream,?ProtocolType.Tcp)){listener.Bind(new?IPEndPoint(IPAddress.Loopback,?0));listener.Listen(1);Task?connectTask?=?Task.Run(()?=>?client.Connect(listener.LocalEndPoint));????????????using?(Socket?server?=?listener.Accept()){????????????????await?connectTask;????????????????using?(var?serverStream?=?new?NetworkStream(server))????????????????using?(var?clientStream?=?new?NetworkStream(client)){Task?serverCopyAll?=?serverStream.CopyToAsync(Stream.Null);????????????????????byte[]?data?=?new?byte[1024];????????????????????new?Random().NextBytes(data);????????????????????var?sw?=?new?Stopwatch();????????????????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);sw.Start();????????????????????for?(int?i?=?0;?i?<?1_000_000;?i++){????????????????????????await?clientStream.WriteAsync(data,?0,?data.Length);}client.Shutdown(SocketShutdown.Send);serverCopyAll.Wait();sw.Stop();Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");}}}} }與之前的Socket一樣，下面我們創建兩個連接的socket，然后把它們包含在NetworkStream中。在其中一個流中，我們將1K數據寫入一百萬次，而另一個流則通過CopyToAsync操作讀出所有數據。在.NET 4.7中，會得到如下輸出：
Elapsed?=?00：00：24.7827947?Gen0?=?220?Gen1?=?3?Gen2?=?0而在.NET Core 2.0中，時間減少了5倍，垃圾回收有效地減少到零：
Elapsed=00:00:05.6456073?Gen0=74?Gen1=0?Gen2=0其它網絡相關組件也將得到進一步優化。例如SslStream通常將圍繞在NetworkStream中，以便向連接中添加SSL。下面的示例將看到這種影響，這個示例將在NetworkStream之上添加SslStream的用法：
using?System;using?System.Diagnostics;using?System.Threading;class?Test {????static?void?Main(){????????while?(true){????????????int?remaining?=?20_000_000;????????????var?mres?=?new?ManualResetEventSlim();WaitCallback?wc?=?null;wc?=?delegate{????????????????if?(Interlocked.Decrement(ref?remaining)?<=?0)?mres.Set();????????????????else?ThreadPool.QueueUserWorkItem(wc);};????????????var?sw?=?new?Stopwatch();????????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);sw.Start();????????????for?(int?i?=?0;?i?<?Environment.ProcessorCount;?i++)?ThreadPool.QueueUserWorkItem(wc);mres.Wait();Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");}} }在.NET 4.7中，會得到如下結果：
Elapsed=00:00:21.1171962?Gen0=470?Gen1=3?Gen2=1.NET Core 2.0包含了諸如dotnet / corefx＃12935和dotnet / corefx＃13274等PR的改進，這兩者都將大大減少了使用SslStream所涉及的分配。在.NET Core 2.0上運行相同的代碼時，會得到如下結果：
Elapsed=00:00:05.6456073?Gen0=74?Gen1=0?Gen2=085％的垃圾收集已被刪除！
?
并發
對于并發和并行性相關的原始化和基礎部分，也得到了許多改進。
這里的一個關鍵點是ThreadPool，它是執行許多.NET應用程序的核心。例如，PR?dotnet / coreclr＃3157減少了QueueUserWorkItem中涉及的某些對象的大小，PR?dotnet / coreclr＃9234使用了ConcurrentQueue <T>重寫來替換ThreadPool的全局隊列，其中會用到較少的同步和分配。從以下的示例中，會看到最終結果：?
using?System;using?System.Diagnostics;using?System.Threading;class?Test {????static?void?Main(){????????while?(true){????????????int?remaining?=?20_000_000;????????????var?mres?=?new?ManualResetEventSlim();WaitCallback?wc?=?null;wc?=?delegate{????????????????if?(Interlocked.Decrement(ref?remaining)?<=?0)?mres.Set();????????????????else?ThreadPool.QueueUserWorkItem(wc);};????????????var?sw?=?new?Stopwatch();????????????int?gen0?=?GC.CollectionCount(0),?gen1?=?GC.CollectionCount(1),?gen2?=?GC.CollectionCount(2);sw.Start();????????????for?(int?i?=?0;?i?<?Environment.ProcessorCount;?i++)?ThreadPool.QueueUserWorkItem(wc);mres.Wait();Console.WriteLine($"Elapsed={sw.Elapsed}?Gen0={GC.CollectionCount(0)?-?gen0}?Gen1={GC.CollectionCount(1)?-?gen1}?Gen2={GC.CollectionCount(2)?-?gen2}");}} }在.NET 4.7中，會等到如下結果：
Elapsed=00:00:03.6263995?Gen0=225?Gen1=51?Gen2=16Elapsed=00:00:03.6304345?Gen0=231?Gen1=62?Gen2=17Elapsed=00:00:03.6142323?Gen0=225?Gen1=53?Gen2=16Elapsed=00:00:03.6565384?Gen0=232?Gen1=62?Gen2=16Elapsed=00:00:03.5999892?Gen0=228?Gen1=62?Gen2=17而在.NET Core 2.0中，會得到如下結果：
Elapsed=00:00:02.1797508?Gen0=153?Gen1=0?Gen2=0Elapsed=00:00:02.1188833?Gen0=154?Gen1=0?Gen2=0Elapsed=00:00:02.1000003?Gen0=153?Gen1=0?Gen2=0Elapsed=00:00:02.1024852?Gen0=153?Gen1=0?Gen2=0Elapsed=00:00:02.1044461?Gen0=154?Gen1=1?Gen2=0這是一個巨大的吞吐量的改善，并且這樣一個核心組件的垃圾量也將大幅減少。
同步原語也在.NET Core中得到提升。例如，低級并發代碼通常使用SpinLock來嘗試避免分配鎖定對象或最小化競爭鎖所花費的時間。PR?dotnet / coreclr＃6952改進了失敗的快速路徑，以下測試會得到顯而易見的結果：
using?System;using?System.Diagnostics;using?System.Threading;class?Test {????static?void?Main(){????????while?(true){????????????bool?taken?=?false;????????????var?sl?=?new?SpinLock(false);sl.Enter(ref?taken);????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?100_000_000;?i++){taken?=?false;sl.TryEnter(0,?ref?taken);}Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，會得到如下結果：
00:00:02.3276463 00:00:02.3174042 00:00:02.3022212 00:00:02.3015542 00:00:02.2974777?
而在.NET Core 2.0中，會得到如下結果：
00：00：00.3915327? 00：00：00.3953084? 00：00：00.3875121? 00：00：00.3980009? 00：00：00.3886977吞吐量的這種差異可能會對運行這種鎖的熱路徑產生很大的影響。
這只是眾多例子中的一個。另一個例子圍繞著Lazy<T>，它被PR?dotnet / coreclr＃8963用manofstick重寫，以便提高訪問初始化過的Lazy <T>的效率。這樣的提升效果從下面的示例中清晰可見：
using?System;using?System.Diagnostics;class?Test {????static?int?s_result;????static?void?Main(){????????while?(true){????????????var?lazy?=?new?Lazy<int>(()?=>?42);s_result?=?lazy.Value;????????????var?sw?=?Stopwatch.StartNew();????????????for?(int?i?=?0;?i?<?1_000_000_000;?i++){s_result?=?lazy.Value;}Console.WriteLine(sw.Elapsed);}} }在.NET 4.7中，會得到的結果如下：
00：00：02.6769712? 00：00：02.6789140? 00：00：02.6535493? 00：00：02.6911146? 00：00：02.7253927而在.NET Core 2.0中，會得到的結果如下：
00：00：00.5278348? 00：00：00.5594950? 00：00：00.5458245? 00：00：00.5381743? 00：00：00.5502970吞吐量增加約5倍。
?
下一步是什么
本文只涉及了部分.NET Core的性能改進。在dotnet / corefx和dotnet / coreclr?repos?中的pull請求中搜索“perf”或“performance”，你會發現接近一千個合并的PR改進。其中一些是比較大的同時也很有影響力的改進，而另一些則主要減少了庫和運行時的消耗，這些變化一起起作用，保證了能夠在.NET Core上更快的運行應用程序。展望未來，性能將成為關注的重點，無論是以性能改進為目標的API還是現有庫的性能的改進。
歡迎大家深入了解.NET Core代碼庫，以便找到影響自己的應用程序和庫的瓶頸，并提交PR來修復它們。如果你的問題得到修復，也請將修復程序分享給所有需要的人。
轉載請注明出自：葡萄城控件
轉載于:https://blog.51cto.com/powertoolsteam/1948165
總結
以上是生活随笔為你收集整理的是什么优化让 .NET Core 性能飙升？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spring Cloud Eureka
- 下一篇： asp.net signalR 专题——