是什麼優化讓 .NET Core 效能飆升？

77rou發表於2017-07-17

原文網址 : http://blog.itpub.net/28298702/viewspace-2142153/

.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=0 Elapsed=00:00:06.4829793 Gen0=954 Gen1=1 Gen2=0 Elapsed=00:00:06.9008532 Gen0=954 Gen1=0 Gen2=0 Elapsed=00:00:06.6485667 Gen0=953 Gen1=1 Gen2=0 Elapsed=00:00:06.4671746 Gen0=954 Gen1=1 Gen2=0

而使用.NET Core 2.0，會得到：

Elapsed=00:00:04.3377355 Gen0=0 Gen1=0 Gen2=0 Elapsed=00:00:04.2892791 Gen0=0 Gen1=0 Gen2=0 Elapsed=00:00:04.3101593 Gen0=0 Gen1=0 Gen2=0 Elapsed=00:00:04.2652497 Gen0=0 Gen1=0 Gen2=0 Elapsed=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=2 Elapsed=00:00:01.1147146 Gen0=2 Gen1=2 Gen2=2 Elapsed=00:00:01.0709146 Gen0=2 Gen1=2 Gen2=2 Elapsed=00:00:01.0706030 Gen0=2 Gen1=2 Gen2=2 Elapsed=00:00:01.0620943 Gen0=2 Gen1=2 Gen2=2

而.NET Core 2.0的結果如下：

Elapsed=00:00:00.1716550 Gen0=1 Gen1=1 Gen2=1 Elapsed=00:00:00.1720829 Gen0=1 Gen1=1 Gen2=1 Elapsed=00:00:00.1717145 Gen0=1 Gen1=1 Gen2=1 Elapsed=00:00:00.1713335 Gen0=1 Gen1=1 Gen2=1 Elapsed=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 data
        byte[] raw = new byte[100 * 1024 * 1024]; for (int i = 0; i < raw.Length; i++) raw[i] = (byte)i; var sw = Stopwatch.StartNew(); // Compress it
        var compressed = new MemoryStream(); using (DeflateStream ds = new DeflateStream(compressed, CompressionMode.Compress, true))
        {
            ds.Write(raw, 0, raw.Length);
        }
        compressed.Position = 0; // Decompress it
        var 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=293 Elapsed=00:00:00.9422960 Gen0=294 Elapsed=00:00:00.9419024 Gen0=294 Elapsed=00:00:00.9417014 Gen0=294 Elapsed=00:00:00.9514724 Gen0=293

在.NET Core 2.0上，會得到以下結果：

Elapsed=00:00:00.6448327 Gen0=11 Elapsed=00:00:00.6438907 Gen0=11 Elapsed=00:00:00.6285656 Gen0=12 Elapsed=00:00:00.6286561 Gen0=11 Elapsed=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=0

85％的垃圾收集已被刪除！

併發

對於併發和並行性相關的原始化和基礎部分，也得到了許多改進。

這裡的一個關鍵點是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=16 Elapsed=00:00:03.6304345 Gen0=231 Gen1=62 Gen2=17 Elapsed=00:00:03.6142323 Gen0=225 Gen1=53 Gen2=16 Elapsed=00:00:03.6565384 Gen0=232 Gen1=62 Gen2=16 Elapsed=00:00:03.5999892 Gen0=228 Gen1=62 Gen2=17

而在.NET Core 2.0中，會得到如下結果：

Elapsed=00:00:02.1797508 Gen0=153 Gen1=0 Gen2=0 Elapsed=00:00:02.1188833 Gen0=154 Gen1=0 Gen2=0 Elapsed=00:00:02.1000003 Gen0=153 Gen1=0 Gen2=0 Elapsed=00:00:02.1024852 Gen0=153 Gen1=0 Gen2=0 Elapsed=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來修復它們。如果你的問題得到修復，也請將修復程式分享給所有需要的人。

轉載請註明出自：葡萄城控制元件

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28298702/viewspace-2142153/，如需轉載，請註明出處，否則將追究法律責任。

通俗易懂，什麼是.NET Core,.NET Core能做什麼
2019-05-17
什麼是Asp.net Core？和 .net core有什麼區別？
2019-01-30
ASP.NET
ASP.NET Core 效能優化最佳實踐
2020-09-14
ASP.NET優化
讓你月薪飆升的祕籍：Java效能調優的9個實用技巧
2018-11-06
Java
Android 效能優化（十二）之我為什麼寫效能優化
2019-03-04
Android優化
Golang net/http 效能優化
2021-04-22
GolangHTTP優化
是什麼讓 .NET 7 的 Min 和 Max 方法效能暴增了45倍？
2022-11-22
天天說要做效能優化，到底在優化什麼？
2020-11-02
優化
為什麼說是時候擁抱.NET CORE了？
2019-07-21
[衝破核心瓶頸，讓I/O效能飆升]DPDK工程師手冊
2021-08-27
工程師
CPU 飆升怎麼辦？
2024-05-22
SEO優化具體是什麼，SEO有什麼優劣呢？
2020-11-25
優化
.Net Core gRPC 是怎麼樣的？
2020-05-21
RPC
巧用FMEA，讓IT專案成功率飆升！
2023-12-19
是什麼讓我開始了元件化？
2018-09-07
元件化
在ASP.NET Core中用HttpClient（四）——提高效能和優化記憶體
2021-03-25
ASP.NETHTTPclient優化記憶體
.NET Standard是什麼
2024-08-01
為什麼選擇ASP.NET Core
2021-06-18
ASP.NET
SEO優化的注意事項是什麼？
2020-07-29
優化
seo優化的價值是什麼呢？
2020-08-31
優化
Spark 3.x Spark Core詳解 & 效能優化
2022-06-01
Spark優化
AI效能狂飆！耕升 GeForce RTX 4070 SUPER 踏雪Mini效能解禁
2024-01-17
AI
DRBD是什麼意思？優缺點是什麼？
2022-04-25
效能優化是個手藝活
2018-10-18
優化
IO優化是怎麼做的，使用 SharedPreferences為什麼這麼卡，mmkv原理是什麼
2020-11-18
優化
【前端效能優化】vue效能優化
2019-04-30
前端優化Vue
淘寶運營：新店如何定位人群！讓訂單暴漲轉化率飆升
2018-09-07
是什麼讓資料分析師變得優秀？- Cassie Kozyrkov
2022-02-21
怎麼做好Java效能優化
2021-12-22
Java優化
【譯】.NET Core 是 .NET 的未來
2019-05-08
[譯]Web 效能優化：圖片優化讓網站大小減少 62%
2019-03-22
Web優化網站
.Net效能調優-ArrayPool
2021-09-13
.Net效能調優-MemoryPool
2021-09-14
伺服器虛擬化部署是什麼有什麼優缺點
2023-03-11
伺服器
.Net Core中無處不在的Async/Await是如何提升效能的？
2022-03-07
AI
.NET Core容器化(Docker)
2018-08-20
Docker
.net core國際化
2020-08-29
.Net Core 國際化
2021-02-09
ASP.NET Core 基於宣告的訪問控制到底是什麼鬼？
2020-09-25
ASP.NET

是什麼優化讓 .NET Core 效能飆升？

集合

LINQ

壓縮

加密

數學運算

序列化

文書處理

檔案系統

網路

併發

下一步是什麼

相關文章