.NET 性能優(yōu)化的技巧
最大化內(nèi)聯(lián)
內(nèi)聯(lián)是將方法體(method body)復(fù)制到調(diào)用站點(diǎn)的技術(shù)，這樣我們就可以避免跳轉(zhuǎn)、參數(shù)傳遞和寄存器保存/恢復(fù)等繁瑣過程。除了節(jié)省這些之外，內(nèi)聯(lián)還是實(shí)現(xiàn)其他優(yōu)化的必要條件。 不不過Roslyn(C#的編譯器)沒有內(nèi)聯(lián)代碼，它是通過JIT實(shí)現(xiàn)的，大多數(shù)優(yōu)化也是如此。
使用靜態(tài)投擲助手(static throw helper)
最近的變化涉及一個(gè)重要的重構(gòu)，在序列化基準(zhǔn)的調(diào)用持續(xù)時(shí)間上增加了大約20ns，從~130ns增加到了~150ns。
罪魁禍?zhǔn)资沁@個(gè)助手方法中添加的throw語句：
- public static Writer<TBufferWriter> CreateWriter<TBufferWriter>(
- this TBufferWriter buffer,
- SerializerSession session) where TBufferWriter : IBufferWriter<byte>
- {
- if (session == null) throw new ArgumentNullException(nameof(session));
- return new Writer<TBufferWriter>(buffer, session);
- }
當(dāng)助手方法中包含throw語句時(shí)，JIT不會內(nèi)聯(lián)它。解決這個(gè)問題的常見技巧是添加一個(gè)靜態(tài)的“throw helper”方法，來完成一些棘手的工作，所以最終結(jié)果如下所示：
- public static Writer<TBufferWriter> CreateWriter<TBufferWriter>(
- this TBufferWriter buffer,
- SerializerSession session) where TBufferWriter : IBufferWriter<byte>
- {
- if (session == null) ThrowSessionNull();
- return new Writer<TBufferWriter>(buffer, session);
- void ThrowSessionNull() => throw new ArgumentNullException(nameof(session));
- }
代碼庫在許多地方使用這個(gè)技巧，將throw語句放在一個(gè)單獨(dú)的方法中可能會有其他好處，例如比如改善常用代碼路徑的位置。
最小化虛擬或接口調(diào)用
虛擬調(diào)用比直接調(diào)用慢，如果你正在編寫一個(gè)關(guān)鍵系統(tǒng)，那么很可能會在分析器中看到虛擬調(diào)用的過程。首先，虛擬調(diào)用需要間接調(diào)用。
去虛擬化是許多JIT編譯器的一個(gè)特性，RyuJIT也不例外。然而，這是一個(gè)復(fù)雜的功能，并且RyuJIT目前可以證明(自身)方法可以被虛擬化并因此成為內(nèi)聯(lián)的候選者的情況并不多。以下是利用虛擬化的一些常規(guī)技巧，但我確信還有更多。
1. 默認(rèn)情況下將類標(biāo)記為sealed，當(dāng)一個(gè)類/方法被標(biāo)記為sealed時(shí)，RyuJIT可以將其考慮在內(nèi)并且可能能夠內(nèi)聯(lián)一個(gè)方法調(diào)用。RyuJIT很可能成為下一代的JIT編譯器。64位計(jì)算已是大勢所趨，即使它并不總是比32位更快或更有效率。當(dāng)前的.NET JIT編譯器就是一個(gè)使得64位計(jì)算機(jī)上有時(shí)導(dǎo)致程序速度減慢的的例子。但是，這將會被改變：一個(gè)新的，下一代x64的JIT編譯器編譯代碼的速度將加快兩倍，它將改變你對64位.NET代碼的印象。
2. 如果可能，將覆蓋(override)方法標(biāo)記為sealed。override可以翻譯為覆蓋，從字面就可以知道，它是覆蓋了一個(gè)方法并且對其重寫，以求達(dá)到不同的作用。對我們來說最熟悉的覆蓋就是對接口方法的實(shí)現(xiàn)，在接口中一般只是對方法進(jìn)行了聲明，而我們在實(shí)現(xiàn)時(shí)，就需要實(shí)現(xiàn)接口聲明的所有方法。除了這個(gè)典型的用法以外，我們在繼承中也可能會在子類覆蓋父類中的方法。
3. 使用具體類型而不是接口，具體類型為JIT提供了更多信息，因此它更有可能內(nèi)聯(lián)你的調(diào)用。
4. 在同一方法中實(shí)例化和使用非sealed對象(而不是使用'create'方法)，當(dāng)類型明確已知時(shí)，比如構(gòu)造之后，RyuJIT可以對非sealed方法調(diào)用進(jìn)行虛擬化。
5. 對多態(tài)類型使用泛型類型約束，以便可以使用具體類型對它們進(jìn)行專門處理，并且可以對接口調(diào)用進(jìn)行非虛擬化。在Hagar中，我們的核心編寫器類型定義如下：
- public ref struct Writer<TBufferWriter> where TBufferWriter : IBufferWriter<byte>
- {
- private TBufferWriter output;
- // --- etc ---
所有對CIL中Roslyn發(fā)出的輸出方法的調(diào)用之前都會有一條約束指令，該指令告訴JIT，該調(diào)用可以對TBufferWriter上定義的精確方法進(jìn)行調(diào)用，而不是進(jìn)行虛擬/接口調(diào)用。這有助于去虛擬化。結(jié)果，所有對在輸出上定義的方法的調(diào)用都被成功地去虛擬化。下面是由JIT團(tuán)隊(duì)的Andy Ayers 編寫的CoreCLR線程，它詳細(xì)描述了當(dāng)前和未來的去虛擬化工作。
減少分配
.NET的垃圾收集器是一項(xiàng)很偉大的項(xiàng)目， 垃圾收集器是 允許對一些無鎖數(shù)據(jù)結(jié)構(gòu)進(jìn)行算法優(yōu)化，并且還可以刪除整個(gè)類的錯(cuò)誤并減輕開發(fā)人員的認(rèn)知負(fù)擔(dān)。總之，垃圾收集是一種非常成功的內(nèi)存管理技術(shù)。
.NET使用bump分配器，其中每個(gè)線程通過找到各自的指針來從每個(gè)線程上下文中分配對象。因此，當(dāng)在同一線程上分配和使用短期分配時(shí)，可以更好的實(shí)現(xiàn)局部緩存(cache locality)機(jī)制。
有關(guān).NET 垃圾收集器的更多信息，請點(diǎn)此了解。
對象池(Object Pool) 或緩沖池(Buffer Pool)
Hagar本身并不管理緩沖區(qū)，而是將責(zé)任轉(zhuǎn)移給用戶。這聽起來可能很麻煩，但實(shí)際上并不麻煩，因?yàn)樗cSystem.IO.Pipelines兼容。因此，我們可以利用默認(rèn)管道通過System.Buffers.ArrayPool
一般來說，重復(fù)使用緩沖區(qū)可以減輕垃圾收集器的壓力。
避免裝箱
盡可能不要通過將值類型轉(zhuǎn)換為引用類型來裝箱值類型。這是常見的建議，但在API設(shè)計(jì)中需要考慮一些因素。在Hagar中，可以接受值類型的接口和方法定義是通用的，以便它們可以專門用于精確類型并避免裝箱/拆箱成本。結(jié)果，沒有熱路徑拳擊。在某些情況下仍然存在拳擊，例如異常方法的字符串格式。可以通過對參數(shù)的顯式. tostring()調(diào)用來刪除那些特定的裝箱分配。
減少關(guān)閉分配
只分配閉包一次，并存儲結(jié)果，就可供多次重復(fù)使用。例如，通常將委托傳遞給ConcurrentDictionary. getoradd。與其將委托編寫為內(nèi)聯(lián)lambda，還不如將define定義為類中的私有字段。下面是來自Hagar中可選ISerializable支持包的一個(gè)例子：
- private readonly Func<Type, Action<object, SerializationInfo, StreamingContext>> createConstructorDelegate;
- public ObjectSerializer(SerializationConstructorFactory constructorFactory)
- {
- // Other parameters/statements omitted.
- this.createConstructorDelegate = constructorFactory.GetSerializationConstructorDelegate;
- }
- // Later, on a hot code path:
- var constructor = this.constructors.GetOrAdd(info.ObjectType, this.createConstructorDelegate);
盡量減少復(fù)制
.NET Core 2.0和2.1以及最近的C#版本，在刪除數(shù)據(jù)復(fù)制過程的方面取得了相當(dāng)大的進(jìn)步。最值得注意的是Span
使用Span
一個(gè)Span
對于.NET Core來說，Span
Hagar廣泛使用Span
通過ref傳遞結(jié)構(gòu)以最小化堆棧上的副本
Hagar使用兩個(gè)主要結(jié)構(gòu)，Reader 和Writer
在沒有干預(yù)的情況下，使用這些結(jié)構(gòu)進(jìn)行的每個(gè)方法調(diào)用都會帶來很大的影響，因?yàn)槊總€(gè)調(diào)用都需要將整個(gè)結(jié)構(gòu)復(fù)制到堆棧中。
我們可以通過將這些結(jié)構(gòu)作為ref參數(shù)傳遞來避免副本的產(chǎn)生，另外，C#還支持使用ref this作為擴(kuò)展方法的目標(biāo)，這非常方便。據(jù)我所知，沒有辦法確保特定的結(jié)構(gòu)類型總是由ref傳遞，如果你不小心在調(diào)用的參數(shù)列表中省略了ref，這可能會導(dǎo)致運(yùn)行錯(cuò)誤。
避免保護(hù)性拷貝(defensive copy)
Roslyn有時(shí)需要做一些工作來保證一些語言不變量，當(dāng)結(jié)構(gòu)存儲在只讀字段中時(shí)，編譯器將插入一些指令，以避免復(fù)制該字段，然后再將其包含到任何能保證不會對其進(jìn)行修改的操作中。通常，這意味著調(diào)用在結(jié)構(gòu)類型本身上定義的方法，因?yàn)閷⒔Y(jié)構(gòu)作為參數(shù)傳遞給在另一類型上定義的方法已經(jīng)需要將結(jié)構(gòu)復(fù)制到堆棧上(除非通過ref或in傳遞)。
如果將
有時(shí)，如果你無法將其定義為只讀結(jié)構(gòu)，則最好在其他不可變結(jié)構(gòu)字段上省略readonly修飾符。
以Jon Skeet的NodaTime庫為例，在這個(gè)示例中，Jon使大多數(shù)結(jié)構(gòu)變?yōu)橹蛔x，因此能夠?qū)eadonly修飾符添加到包含這些結(jié)構(gòu)的字段中，而不會對性能產(chǎn)生負(fù)面影響。
減少分支和分支錯(cuò)誤預(yù)測
現(xiàn)代cpu依賴于長pipeline的指令，這些指令通過并發(fā)性進(jìn)行處理。這涉及到CPU分析指令，以確定哪些指令不依賴于前面的指令，還涉及猜測將采用哪些條件跳轉(zhuǎn)語句。為此，CPU使用一個(gè)名為分支預(yù)測器(branch predictor)的組件，該組件負(fù)責(zé)猜測將采用哪個(gè)分支。它通常通過讀取和寫入表中的條目來實(shí)現(xiàn)這一點(diǎn)，并根據(jù)上次執(zhí)行條件跳轉(zhuǎn)時(shí)發(fā)生的情況修改其預(yù)測。
當(dāng)預(yù)測正確時(shí)，就會加快進(jìn)程，否則就需要把預(yù)測分支的指令排空，重新獲取正確分支的指令進(jìn)入pipeline繼續(xù)執(zhí)行。
所以加快進(jìn)程的最好辦法就是減少分支和分支錯(cuò)誤預(yù)測，首先嘗試最小化分支數(shù)量，如果無法消除分支，請盡量減少錯(cuò)誤預(yù)測率，這可能涉及使用排序數(shù)據(jù)或重構(gòu)代碼，可以用查找的辦法來代替分支預(yù)測。
其他雜項(xiàng)提示
1. 避免使用LINQ，LINQ在應(yīng)用程序代碼方面很出色，但在庫/框架代碼中很少被用于路徑。LINQ很難對JIT進(jìn)行優(yōu)化(IEnumerable
2. 使用具體類型而不是接口或抽象類型，也許最常見的是，如果你在List
3. 反射在庫代碼中特別有用，緩存反射結(jié)果，考慮使用IL或Roslyn為訪問器生成委托，或者更好的方法是使用現(xiàn)有的庫，如Microsoft.Extensions.ObjectMethodExecutor.Sources，Microsoft.Extensions.PropertyHelper.Sources或FastMember。
特定于庫的優(yōu)化
優(yōu)化生成的代碼
Hagar使用Roslyn為要序列化的POCO生成C#代碼，這個(gè)C#代碼在編譯時(shí)包含在你的項(xiàng)目中。我們可以對生成的代碼執(zhí)行一些優(yōu)化，以加快速度。
通過跳過對已知類型的編解碼器查找來避免虛擬調(diào)用
當(dāng)復(fù)雜對象包含眾所周知的字段(如int，Guid，string)時(shí)，代碼生成器將直接插入對這些類型的手動編碼編解碼器的調(diào)用，而不是調(diào)用CodecProvider來檢索該類型的IFieldCodec
在運(yùn)行時(shí)專門化泛型類型
與上面類似，代碼生成器可以生成在運(yùn)行時(shí)使用專門化的代碼。
預(yù)先計(jì)算常數(shù)值以消除某些分支
在序列化期間，每個(gè)字段都帶有一個(gè)標(biāo)頭，通常是一個(gè)字節(jié)。它會告訴解串器哪個(gè)字段是編碼的。此字段標(biāo)題包含3條信息：字段的規(guī)格(固定寬度、長度前綴、標(biāo)記分隔、引用等)，字段的模式類型(預(yù)期、眾所周知、以前定義的、編碼)用于多態(tài)，并將最后3位專用于編碼字段id(如果它小于7)。在許多情況下，可以確切地知道在編譯時(shí)這個(gè)標(biāo)頭字節(jié)是什么。如果字段具有值類型，那么我們就知道運(yùn)行時(shí)類型永遠(yuǎn)不能與字段類型不同，并且始終知道字段id。
因此，我們通常可以保存計(jì)算標(biāo)頭值所需的所有工作，并可以直接將其作為常量嵌入到代碼中。這樣可以節(jié)省分支并且通常會消除大量的中間語言代碼。
選擇適當(dāng)?shù)臄?shù)據(jù)結(jié)構(gòu)
通過切換到結(jié)構(gòu)數(shù)組，很大程度上消除了索引和維護(hù)集合的成本，并且參考跟蹤不再出現(xiàn)在基準(zhǔn)測試中。這有一個(gè)缺點(diǎn)，對于大型對象圖，這種新方法可能較慢。
選擇合適的算法
Hagar花費(fèi)大量時(shí)間對可變長度整數(shù)進(jìn)行編碼/解碼，這種方法被稱為varints，varints是用一個(gè)或多個(gè)字節(jié)序列化整形的一種方法，以減小有效載荷的大小。許多二進(jìn)制序列化器使用這種技術(shù)，包括協(xié)議緩沖區(qū)。甚至.NET的BinaryWriter也使用這種編碼。下面是參考資料的一小段：
- protected void Write7BitEncodedInt(int value) {
- // Write out an int 7 bits at a time. The high bit of the byte,
- // when on, tells reader to continue reading more bytes.
- uint v = (uint) value; // support negative numbers
- while (v >= 0x80) {
- Write((byte) (v | 0x80));
- v >>= 7;
- }
- Write((byte)v);
- }
我想指出ZigZag編碼對于包含負(fù)值的有符號整數(shù)可能更有效，而不是強(qiáng)制轉(zhuǎn)換為uint。
這些序列化器中的變量使用稱為Little Endian Base-128或LEB128的算法，該算法每字節(jié)編碼多達(dá)7位。它使用每個(gè)字節(jié)的最高有效位來指示是否跟隨另一個(gè)字節(jié)(1 =是，0 =否)。這是一種簡單的格式，但可能不是最快的。不過PrefixVarint更快，使用PrefixVarint，所有來自LEB128的1都是在有效載荷的開頭一次性寫入的。這可能讓我們使用硬件內(nèi)在函數(shù)來提高這種編碼和解碼的速度。通過將大小信息往前移，我們也可以從有效載荷中一次讀取更多字節(jié)，從而減少內(nèi)部壓力并提高性能。
