以下內容來自公眾號逆鋒起筆，關注每日干貨及時送達

作者 ｜ Vicent Marti

譯者 ｜ 核子可樂

策劃 ｜ 褚杏娟

Go 1.18 已經到來，很多人期盼已久的首個支持泛型實現的版本也就此落地。之前，泛型一直是個熱度很高、但在整個 Go 社區中備受爭議的話題。

一方面，批評者們擔心泛型的引入會增加復雜性，導致 Go 語言最終變得像 Java 那樣冗長繁復，也有人害怕 Go 語言退化成 HaskellScript，用 Monad 代替 if。平心而論，這兩種擔憂都有點極端。另一方面，支持者們則認為要實現大規模代碼清潔、可重用的目標，泛型不可或缺。

本文不打算參與這場論戰，也不打算探討哪些情況下適合在 Go 中使用泛型。這里，我們主要著眼于泛型難題的第三個方面：不想用泛型的系統工程師們該怎么辦，特別是單態化給性能造成的影響。這樣的工程師不少，這類人對泛型的性能表現都相當失望。

Go 1.18 中的泛型實現

我們其實可以用多種不同的方式在編程語言中實現參數多態化（我們常稱之為「泛型」）。在切入正題前，我們先聊聊問題背景、明確 Go 1.18 已經采用的解決方案。雖然這是篇關于系統工程的文章，但我會盡量讓討論氛圍輕松愉快、通俗易懂。

假設大家想創建一個多態函數，即能對不同事物執行模糊操作的函數。從廣義上講，能夠選擇的解決思路有兩種。

第一種是讓一切事物（也就是函數操作對象）保持統一的觀感與行為模式。這種方法也稱為“裝箱”，主要思路就是先進行堆上內容分配、再把相應的指針傳遞給函數。因為所有操作對象都轉化成了指針，我們只需要指針操作就能了解這些對象在哪里。但也因為指針太多，我們還需要創建一份函數指針表，也就是大家常說的“虛擬方法表”或 vtable。這聽起來很熟悉吧？Go 接口就是這么實現的，Rust 中的 dyn Traits 以及 C++ 中的虛擬類也是差不多類似的思路。這些多態形式在實踐中更加易用，但表達能力和運行時資源消耗都不太樂觀。

而第二種是對不同事物進行操作的方法，即“單態化”。這名字聽起來很唬人，但實際上相對簡單很多。它的基本思路就是為每個獨特的操作對象創建一個函數副本。沒錯，就是這樣簡單。假設我們的函數能添加兩個數字，現在我們想讓它添加兩個 float64 數，編譯器就會為該函數創建副本并將泛型占位符替換為 float64，之后再進行函數編譯。這也是目前最簡單的多態實現方法（雖然在實際操作中也經常卡住），但會給編譯器帶來很高的運行壓力。

從歷史上看，C++、D 乃至 Rust 等系統語言一直采用單態化方法實現泛型。造成這一現實的原因很多，但總體來說就是想用更長的編譯時間來換取結果代碼的性能提升，并且只要我們能提前把泛型代碼中的類型占位符替換成最終類型、再進行編譯，就可以極大優化編譯流程的性能表現。裝箱方法就做不到這一點。另外，我們還可以對函數調用進行去虛擬化以回避 vtable，甚至使用內聯代碼實現進一步優化。

總之，單態化在系統編程語言領域取得了壓倒性的勝利——畢竟它在本質上不會給運行時造成額外負擔，有時候甚至反而能提高泛型代碼的運行速度。

但作為一個致力于提升大型 Go 應用程序性能水平的從業者，我對在 Go 中引入泛型并不感冒。我比較支持單態化帶來的優化潛力，但 Go 編譯器在處理接口時根本實現不了這類優化。更讓人失望的是，Go 1.18 中的泛型實現依靠的根本不是單態化，至少不完全是。

這實際是一種被稱為“GCShape stenciling with Dictionaries”的部分單態化技術。為了方便起見，下面我就向大家簡要介紹一下這項技術的基本思路。

這項技術的基本思路如下：既然根據輸入參數對各個函數調用進行完全單態化會生成大量額外代碼，我們不妨超越參數類型、以更為廣泛的單態化減少這些“唯一函數”的數量。因此，在這樣的泛型實現思路下，Go 編譯器會基于參數的 GCShape（而非類型）執行單態化（我們將其稱為「stenciling」）。

類型的 GCShape，是一種特定于 Go 語言及泛型實現的抽象概念。根據設計文檔中的說法，對于任意兩個具體類型，只要二者具有相同的基礎類型、或者皆屬于指針類型時，就會被劃分在同一 gcshape 分組內。定義中的前半部分很好理解：如果我們要對某個方法的參數執行自述運算，Go 編譯器就會根據其類型有效進行單態化。這樣，使用整數運算指令生成的 uint32 代碼就與使用浮點運算指令的 float64 代碼有所不同。另一方面，針對 uint32 類型別名生成的代碼則與底層 uint32 的代碼相同。

說到這里，一切似乎都很美好。然而，GCShape 的后半部分定義卻對性能產生了巨大影響。需要強調的是：所有指向對象的指針都屬于同一 GCShape，不論其具體指向哪個對象。這意味著＊time.Time 指針跟＊uint64 指針、＊bytes.Buffer 指針乃至＊strings.Builder 指針全都歸屬于同一 GCShape。

這不禁讓我們懷疑“如果我們想在這些對象上調用方法，又會怎么樣？這些方法的位置不會也歸屬于同一 GCShape 吧？”其實這個問題的答案已經蘊藏在 GCShape 這個名稱里了：它根本不知道什么叫方法。要解釋這一點，我們還得從 GCShape 使用的字典入手。

在 1.18 版本中的當前泛型實現中，泛型函數的每一次運行時調用都會以透明方式接受靜態字典作為其第一條參數，字典中包含了關于傳遞給函數的參數元數據。該字典放置在 AMD64 的寄存器 AX 當中，而且 Go 編譯器目前還無法在這些堆棧中支持基于寄存器的調用約定。

受篇幅所限，這里我們不糾結字典的完整實現。總而言之，字典中包含所有必需的類型元數據，用來將參數進一步傳遞給其他泛型函數，由此實現函數到 / 自接口的轉型。其中對用戶影響最大的就是如何在泛型函數上調用方法。

沒錯，在單態化步驟完成后，生成的函數 shape 需要將所有泛型參數的 vtable 當作運行時輸入。從直觀感受上，這雖然大大減少了所生成的唯一代碼的數量，但過于廣泛的單態化思路也消滅了去虛擬化、內聯或其他性能優化的實施空間。

事實上，對于大多數 Go 代碼而言，泛型機制似乎確實對性能存在影響。但為了證明這個結論的嚴謹性，我們還要通過基準測試、程序集及行為驗證給出實錘。

接口內聯

VItess 是 PlanetScale 采用的開源分布式數據庫，同時也是一款規模龐大、結構復雜的真實 Go 應用程序，特別適合作為 Go 語言新功能（特別是與性能相關的功能）的測試平臺。我碰巧在 Vitess 上找到了一長串手動單態化的函數與實現。其中一部分重復函數是受到多態性所限而無法用接口建模；也有一部分重復函數是因為對性能至關重要，所以避免用接口編譯能帶來顯著的性能提升。

下面我們來看看這份列表中的具體選項：sqltypes 包中的 BufEncodeSQL 函數就不錯。我把這些函數復制過來，并附上＊strings.Builder 或者＊bytes.Buffer 指針，這樣就能對緩沖區執行大量調用了。如果緩沖區作為未裝箱類型（而非接口類型）進行傳遞，編譯器就能對這些調用進行內聯。如此一來，在整個代碼庫內廣泛使用的函數將迎來相當顯著的性能增強。

單對這段代碼進行泛化還不夠，我們還得把函數的泛型版本跟以 io.ByteWriter 為接口的簡易版本進行比較。

io.ByteWriter 這邊的程序集沒什么亮點：所有 WriteByte 調用都通過 itab 發生。我們稍后會具體解釋這意味著什么。而另一邊的泛型版本卻非常有趣，我們首先看到編譯器為函數 (BufEncodeStringSQL[go.shape.＊uint8_0]) 生成了單一 shape 實例。雖然我們并未在內聯視圖中顯示，但還是得在可訪問代碼中使用＊strings.Builder 才能調用這條泛型函數；否則，編譯器根本不會為函數生成任何實例：

因為這里我們使用＊strings.Builder 作為調用函數的參數，所以在生成的程序集中看到了＊uint8 shape。如前所述，所有將指針作為泛型參數的泛型調用都會被 stencil 為 *uint8 形式，無論具體指向哪種對象。對象的實際屬性（最重要的就是其 itab）則存儲在大家泛型函數的字典內。

整個過程跟設計文檔的說明完全相符：用于傳遞指向結構的 stenciling 過程會將指針單態化為類似 void 的指針。單態化期間不考慮指向對象的其他屬性，因此無法進行內聯。對于可以內聯的結構，相關方法的具體信息僅在運行時上的字典中可用。簡單來講，這種 stenciling 機制的設計思路就不允許開發者對函數調用進行去虛擬化，也因此消滅了編譯器進行內聯的空間。但這還不算完。

將生成的程序集調用接口代碼中的 WriteByte 方法與泛型代碼進行比較，我們就能對泛型代碼開展深入性能分析。

中場休息：調用 Go 中的接口方法

在比較兩個代碼版本的調用之前，我們不妨快速回顧一下 Go 語言中的接口是如何實現的。之前我們已經提到，接口是一種涉及裝箱的多態形式，用以確保我們操作的所有對象具有相同的 shape。Go 接口的 shape 是一個 16 字節的胖指針（iface），其中前半部分指向關于裝箱值的元數據（我們稱之為 itab），后半部分則指向值本身。

itabk 中包含大量關于接口內部類型的信息。inter、_type 及 hash 字段則包含實現接口間轉換、接口類型反射及切換的必要元數據。這里我們著重討論 itab 末尾的 fun 數組：雖然這部分在類型描述中顯示為 [1]uintptr，但它實際上卻屬于變長分配（variable-length allocation）。itab 結構的大小會根據不同接口而變化，結構的末尾則有足夠的空間來存儲接口內各個方法的函數指針。每次調用接口上的方法，我們都需要訪問這些函數指針，所以它們就相當于 Go 版本的 C++ vtable。

考慮到這一點，現在我們就能理解在函數的非泛型實現當中如何調用接口方法的程序集了。下面是第 8 行 buf.WriteByte('\') 部分的編譯結果：

要在 buf 上調用 WriteByte 方法，我們首先需要一個指向 buf 的 itab 指針。雖然 buf 最初是通過一對寄存器傳遞至函數中的，但編譯器會在函數體開頭將其溢出至棧內，以確保它能在其他對象上使用寄存器。要調用 buf 上的方法，我們首先需要將 *itab 從棧中加載回寄存器（CX），之后可以取消引用 CX 中的 itab 指針，借此訪問其字段：我們將 offset 24 處的雙字移動至 DX 內；回顧一下 itab 原始定義，就會發現 itab 中的第一個函數指針就在 offset 24 處。到這里，整個設計還是很符合邏輯的。

DX 中包含我們要調用的函數地址，但我們還沒有它的參數。Go 語言中的“struct-attached 方法”相當于為獨立函數加糖，可以使目標函數將接收方設為首個參數，例如將 func (b＊Builder) WriteByte(x byte) 加糖成 func "".(＊Builder).WriteByte(b＊Builder, x byte)。這樣，函數調用的第一個參數就必須是 buf.(＊face).data，即指向我們接口內 strings.Builder 的實際指針。該指針在棧內可用，位于我們剛剛加載的 tab 指針的 8 個字節之后。最后，函數中的第二個參數就直接是\, (ASCII 92)，我們可以 CALL DX 執行自己的方法。

是的，單單調用一個簡單方法就得費這么大勁。但有一說一，代碼的實際性能還可以。最大的問題就是接口調用總會影響 incline——因為調用的實際開銷來自從 itab 中加載函數地址的單一指針解引用。之后我們會對此進行基準測試，看看解引用到底要占用多少性能。但先讓我們看看泛型代碼。

回歸泛型：指針調用

下面說回泛型函數的程序集。請注意，這里我們要分析 *uint8 生成的實例化 shape，因為所有指針實例化 shape 都會使用相同的、類似于 void 的指針類型。以下為 buf 上的 WriteByte 方法調用方式：



看著很熟悉，但其中最大的區別就是 offset 0x0094 中存在我們不希望出現在函數調用點上的內容：另一個指針解引用。用人話來解釋：因為我們把所有指針 shape 都單態化成了＊uint8 的單一 shape 實例，所以該 shape 就不再包含可以在指針上調用哪些方法的信息。可這些信息還是必要的，該保存在哪里？理想情況下，自然是放置在與指針相關聯的 itab 當中。但因為我們的函數 shape 采用單一 8 字節指針作為 buf 參數——而非接口那樣的 16 字節胖指針＊itab 與數據字段——所以也就不存在與指針直接關聯的 itab。出于這一現實，stenciling 實現才需要向每一個泛型函數調用傳遞字典：字典中包含的，就是指向函數所有泛型參數的 itab 的指針。

說到這里，大家應該理解為什么我們的程序集要費力使用字典了。使用 CX 中的字典，我們就能實現解引用，并在 offset 64 處找到需要使用的 *itab。很遺憾，現在我們還得到另外一項解引用（24（CX））從 itab 內部加載函數指針。方法調用與之前的代碼相同，這里不再贅述。

這種額外的解引用在實踐上到底有多大影響？直觀來講，我們可以認定在泛型函數中調用對象的方法，總是要比在直接將接口作為參數的非泛型函數中要慢。這是因為泛型會把之前的指針調用轉換成兩次間接接口調用，所以速度一定會比常規接口調用慢。



在這項簡單的基準測試中，我們使用 3 種略有差異的實現測試同一函數體。GenericWithPointer 會向我們的 EscapeW io.ByteWriter 泛型函數傳遞＊strings.Builder；iface 基準測試則是直接采用接口的 Escape(io.ByteWriter, []byte)；monomorphized 使用的是手動單態化的 Escape(＊strings.Builder, []byte) 函數。

結果也基本符合預期。直接獲取 *strings.Builder 的函數速度最快，因為它允許編譯器對 WriteByte 調用進行內聯。泛型函數的速度則比將 io.ByteWriter 接口作為參數的最簡實現慢得多。可以看到，泛型字典帶來的額外性能影響不算太大，畢竟這個基準測試體量很小，itab 與泛型字典的緩存命中率都有保證（別急，后文會討論緩存爭用給泛型代碼帶來的性能影響）。

這就是我們從分析中得到的第一個結論：在 1.18 中，我們沒必要將帶有接口的純函數轉換成泛型函數，因為 Go 編譯器目前無法生成通過指針調用方法的函數 shape，所以轉換只會拖慢代碼運行速度。為了適應轉換，編譯器會引入兩次非必要間接接口調用，這跟我們去虛擬化、盡可能內聯的優化思路明顯是南轅北轍。

在結束本節之前，我們還想聊聊 Go 編譯器中逃逸分析的一個細節。可以看到，單態化函數在我們的基準測試中有 2 個 allocs/op。這是因為我們傳遞了一個指向棧內 strings.Builder 的指針，編譯器可以證明它沒有逃逸，因此不需要堆分配。而盡管我們也從該棧中傳遞了一個指針，Iface 基準測試卻顯示出 3 個 allocs/op。這是因為我們把指針移動到接口，因此總是進行分配。但奇怪的是，GenericWithPointer 實現同樣顯示 3 個 allocs/op，說明即使直接為函數生成的實例采用指針，轉義分析也無法證明其屬于非轉義，所以就會額外增加一次堆分配。這確實是個問題，但正如前文提到，真正的大麻煩還在后頭。

泛型接口調用

在之前幾節中 ，我們已經使用＊strings.Builder 調用了泛型 Escape 函數，并查看由此生成的 shape 完成了代碼分析。大家應該還記得，我們方法的泛型簽名為 EscapeW io.ByteWriter，而＊strings.Builder 必然滿足此約束條件，因此能夠產生 *uint8 的實例化 shape。

但如果我們把 *strings.Builder 隱藏的接口之后，情況會發生怎樣的變化？



現在，我們泛型函數的參數成了接口，而不再是指針。但調用仍然明顯有效，因為我們傳遞的接口跟我們方法中的約束條件相同。但這時候生成的實例化 shape 會如何變化？這里我們沒有嵌入完整的反匯編代碼，畢竟太雜亂了；跟之前一樣，我們直接對函數中 WriteByte 方法的調用點進行分析：

這跟之前生成的代碼完全不一樣了。看來測量各個調用點上的額外解引用不是什么好辦法，那我們該怎么掌握額外的函數調用？

先看看目前的狀況：我們可以在 Go 運行時中找到 runtime.assert|2|方法，它是在接口間對轉換做出斷言的幫助器。它會接收＊interfacetype 與＊itab 作為兩項參數，并僅當給定 itab 中的接口也實現了我們的目標接口時、才返回給定 interfacetype 的 itab。不知道大家能否明白？

假設我們有如下接口：



這個接口并沒有提到 io.ByteWriter 或者 io.Writer，但任何實現 IBuffer 的類型也將隱式實現這兩個接口。這自然會影響到我們泛型函數的編譯：因為我們函數的泛型約束為 [W io.ByteWriter]，所以可以將任何實現 io.ByteWriter 的接口作為參數進行傳遞——其中也包括 IBuffer。

但當我們需要在參數上調用 WriteByte 方法時，該如何判斷此方法在我們接到的接口 itab.fun 數組上的具體位置？這個說不好。因為如果我們將 *strings.Builder 以 io.ByteWriter 接口的形式傳遞，那么該接口中的 itab 必然會把方法放置在 fun[0] 處；如果作為 IBuffer 傳遞，那它就在 fun[1] 處。所以我們需要一個幫助器，它可以將 itab 用作 IBuffer，并為 io.ByteWriter 返回一個 itab，其中我們的 WriteByte 函數指針始終處于 fun[0] 位置。

這就是 assert|2|的意義所在，函數內的每一個調用點也都是如此。下面咱們一步步具體分析。



首先，它會把 io.ByteWriter（因為屬于我們在約束中定義的接口類型，所以屬于全局硬編碼）的 interfacetype 加載到 AX 中。之后，它將我們傳遞給函數的接口的實際 itab 加載至 BX 中。到這里，assert|2|就獲得了兩個必要參數；調用 assert|2|后，我們就得到了 AX 中 io.ByteWriter 的 itab，可以像在之前的編譯代碼中那樣繼續調用接口函數，并保證函數指針永遠處在 itab 內的 offset 24 處。本質上，這一 shape 實例就是把每項方法調用從 buf.WriteByte(ch) 轉換為 buf.(io.ByteWriter).WriteByte(ch)。

沒錯，一聽就很費性能，而且看起來也很多余。難道不能在函數開始時只獲取一次 io.ByteWriter itab，再在后續的所有函數調用中重復使用嗎？答案是在大多數情況下不行，只有少數函數 shape 能夠安全采取這種方法（例如我們目前正在分析的函數）。

這是因為 buf 接口中的值永遠不會改變，所以我們不需要執行類型切換、或者將 buf 接口向下傳遞至棧內其他函數處。Go 編譯器肯定還有優化空間，所以我們從基準數據出發，看看這樣的優化思路能產生多大影響：



效果一般。assert|2|調用明顯很費性能，就連在我們這個不再進一步調用其他函數的函數中也能看得出來。執行速度幾乎是直接調用 WriteByte 手動單態函數的兩倍，比直接使用無泛型 io.ByteWriter 接口也要慢 30%。這肯定是個需要注意的性能問題：相同的泛型函數、相同的參數，相較于直接以指針形式傳遞參數，在接口內部傳遞參數會顯著影響性能。

還沒結束。事實證明，我們的 GenericWithExactIface 基準測試才是最好的方案，因為函數中的約束為 [W io.ByteWriter]，而且我們將參數以 io.ByteWriter 接口的形式傳遞。如此一來，runtime.assert|2|調用會立即返回我們傳遞給它的 itab，因為它與我們 shape 實例正在尋找的 itab 完全匹配。但是，如果我們將參數作為先前定義的 IBuffer 接口進行傳遞，情況會有何不同？照理說不會有影響，畢竟 *strings.Builder 可以實現 IBuffer 與 io.ByteWriter，但在運行時中，函數中的每一次方法調用都會在 assert|2|嘗試從 IBuffer 參數中獲取 io.ByteWriter itab 時產生一個全局 hash 表。



這個發現非常重要，我們可以看到性能問題已經快變成性能黑洞了，具體影響取決于我們傳遞給泛型函數的接口匹配的是它的約束、還是約束的超集。

所以，我們得到一個明確的結論：千萬別把接口傳遞給 Go 中的泛型函數。即使在最理想的情況下，即接口與約束完全匹配時，指向類型的每一次方法調用都會產生大量開銷。而如果接口屬于約束的超集，那么每一次方法調用都需要通過 hash 表進行動態解析，而且這項功能根本無法被納入緩存。

在本節結束之前，我們再來整理一下思路。要想確定 Go 泛型是否適合您的用例，我們還需要明確以下幾點：

上述基準測試中的數字還是理想條件下的結果，特別是在接口調用方面，這些結果無法代表現實應用程序中的函數調用開銷。我們的小型基準測試完全是在實驗環境下進行，泛型函數的 itab 與字典擁有很高的緩存命中率，而且啟用 assert|2|的全局 itabTable 為空且不存在爭用。但在實際生產服務中必然存在緩存爭用，而且全局 itabTable 往往包含幾十甚至上百萬個條目，具體取決于服務運行了多長時間、編譯代碼中包含多少唯一類型 / 接口。總之，代碼庫的復雜度越高，Go 程序中泛型方法的調用開銷就越大，而這種性能降級會對 Go 程序中的所有接口檢查造成影響，只不過這些接口檢查不會像函數調用那樣始終以緊密循環的形式執行。

那有沒有辦法在合成環境下，對這種性能降級開展基準測試？當然有，但結果也不是特別可靠。我們可以用條目污染全局 itabTable，同時不斷從一個單獨的 Goroutine 中丟棄 L2 CPU 緩存。這種方法確實能隨機增加基準測試中泛型代碼的方法調用開銷，但沒法在 itabTable 中準確重現我們在實時生產服務中看到的爭用模式，所以測量出的開銷很難跟真實場景聯系起來。

盡管如此，基準測試還是給了我們不少啟發。我們至少了解到 Go 1.18 中不同編譯代碼中的方法調用，各自在小規模基準測試中產生了怎樣的開銷（每次調用以納秒計）。受試方法包含一個非內聯空主體，因此能夠保證單純是在測量調用開銷。基準測試共運行 3 次，分別為：理想條件，L2 緩存連續丟棄，丟棄緩存且加大全局 itabTable（其中包含 itab 查找爭用）。



可以看到，理想條件下的方法調用開銷跟我們在 Escape 基準測試中看到的基本類似，而一旦加入爭用，情況就會發生有趣的變化：如大家所料，非泛型方法的調用性能不受 L2 緩存爭用的影響，而所有泛型代碼的開銷則會因爭用而小幅增長（即使不訪問全局 itabTable 也是如此，這可能是因為所有泛型方法調用都必須訪問更大的運行時字典）。

當我們進一步增加 itabTable 的大小與 L2 緩存丟棄時，真正的災難發生了：每一次方法調用都會引發大量開銷，這是因為全局 itabTable 過大、根本無法放入緩存，而且相關條目也無法命中。再次強調，我們這次小型基準測試屬于定性測量，無法給出有意義的開銷增量，具體還是要看生產環境中 Go 應用程序的復雜性與負載強度。

總之，這次實驗的最大收獲，就是提醒大家 Go 泛型代碼中潛藏著這種性能“殺手”，必須想辦法加以排除。

字節序列

在 Go 代碼庫，還有另一種常見的模式，甚至在標準庫中也時有出現。這就是某一函數在將一段 []byte 作為自己函數的同時，還會保留一個與之等價的字符串。

這種模式真的無處不在（例如 (＊Buffer).Write 和 (＊Buffer).WriteString），這里我們以 encoding/utf8 包為例：其中約 50% 的 API 表面為重復方法，已經進行手動單態化以支持 []byte 和 string。



需要強調的是，這種重復本身其實是一種性能優化：API 很可能只提供 []byte 函數以操作 UTF8 數據，相當于強制用戶在調用包前將 string 輸入轉換為 []byte 。這雖然更符合使用習慣，但也相當吃性能。由于 Go 中的字節切片是可變的，而字符串不可變，所以二者之間的相互轉換將始終強制執行分配。

泛型存在的意義，就是消除這類隨處可見的代碼重復，但這里的重復代碼是為了防止額外分配，所以在統一具體實現之前，我們先得保證生成的 shape 實例在行為上與預期相符。

下面，我們來比較 Valid 函數的兩個不同版本：encoding/utf8 中的原始函數以 []byte 為輸入，而新的泛型函數則受 byteseq 約束——這是一個非常簡單的 string | []byte 約束，允許我們對這兩種參數類型進行互換。

在查看新泛型函數的 shape 之前，我們應該先看看非泛型編譯中的一些優化細節，通過比較確定這些優化在泛型實例化的過程中是否仍然存在。從中，我們能發現兩項好優化和一項爛優化：

首先，Go 1.16 版本引入了基于寄存器的 Go 調用約定，這就特別適合優化我們的 []byte 參數。現在，切片頭的 24 個字節不會被推送進棧，而是作為 3 個指針在 3 個寄存器中單獨傳遞：切片的 *byte 指針駐留在整個函數體的 AX 內，長度駐留在 BX 內，而且絕不會溢出。這樣我們就能高效使用寄存器來實現相對復雜的表達式，例如把 len(p) >= 8 編譯成 CMPQ BX, $8。同樣的，從 p 中加載 32/64 bit 也會被優化成從 AX 中加載 MOVL + ORL 。

這條編譯函數中唯一不好的部分出現在主 for 循環中：第 19 行的 pi := p[i] 加載包含一項邊界檢查，但這步檢查本該通過以上循環頭中的 i < n 實現。從生成的程序集中可以看到，我們實際上是連續鏈接了兩次跳轉：一次是 JGE（有符號比較指令）、一次是 JAE（無符號比較指令）。這個問題比較隱蔽，根源是 Go 語言中 len 的返回值是經過簽名的。也許我們可以單開一文，具體講講這個問題。

總之，這個 Valid 函數的非泛型編譯代碼還是挺不錯的，接下來就是跟泛型實例進行比較。這里我們只看 []byte 參數的 shape；使用 string 參數調用泛型函數會生成不同的 shape，這是因為二者的內存布局不同（string 為 16 字節，而 []byte 為 24 字節），所以即使二者在實例化 shape 中的使用方式相同，區別也仍然存在。這里，我們僅以只讀方式訪問字節序列。

結果很好，甚至可以說是相當好。我們發現在這個用例中，泛型確實能幫助代碼實現重復部分刪除，而且不會造成性能減退。這個結果令人興奮：從頭到尾，可以看到所有優化仍然成立（這里沒有顯示，但 string shape 也得到了優化）。基于寄存器的調用約定在泛型實例中仍然存在，只是現在 []byte 參數的長度現在駐留在 CX、而非 BX 中：所有寄存器都向右移動了一個 slot，這是因為 AX 現在由泛型負責實現。

其他一切就非常整潔精練了：32/64 bit 加載仍然分為兩條指令，非泛型版本中省略的少數邊界檢查在這里仍然省略，而且完全沒有引入任何額外開銷。

下面來看兩種實現的簡單基準測試結果：

這兩種實現間的性能差異基本屬于正常的誤差范疇，所以可以算是最理想的結果了：[]byte | string 約束可用于 Go 泛型，能夠減少負責處理字節序列的函數中的代碼重復，而且不會引入任何額外開銷。但這里也有例外：在運行 ASCII 基準測試時，即使二者的程序集功能完全相同，string 的泛型 shape 還是要比非泛型實現快不少（約 4%）。這種情況著實令人費解，而且只能在輸入為 ASCII 的基準測試中重現。

函數回調

從最早的版本起，Go 對匿名函數的支持就相當友好。作為 Go 語言的核心特性，匿名函數允許在不改變語言語法的前提下大大增加多種模式的長度來強化表達能力。例如，用戶代碼無法通過擴展在自定義結構或接口上調用范圍運算符時，就可以使用匿名函數。所以為了支持迭代，我們的數據結構就必須要實現自定義迭代器結構（開銷很大），或者使用速度更快、基于函數回調的迭代 API。下面來看個小例子，這里使用函數回調遍歷 UTF-9 編碼字節切片中的所有有效符文（即 Unicode 代碼點）：

拋開基準測試：與使用 for _, cp := range string(p) 的常規迭代相比，大家覺得這個函數的性能是更好還是更差？沒錯，答案是更差。這是因為 string 上的范圍循環包含內聯迭代主體，所以只有最理想的情況（即純 ASCII 字符串）才能在不調用任何函數的情況下完成。而在我們的自定義函數中，必須要為每個符文（rune）發出回調。

如果我們能用某種方法為函數內的每個回調實現內聯，就能把性能拉升至類似 ASCII 字符串范圍循環的水平，甚至在處理 Unicode 字符串時實現速度反超！但是，如何才能讓 Go 編譯器對我們的回調進行內聯？這確實是個難解的問題，畢竟我們傳遞的回調并不會在本地函數中執行、而是作為迭代的一部分在 ForEachRune 內部執行。為了將回調內聯至迭代器中，我們必須使用特定回調對 ForEachRune 副本進行實例化。但 Go 編譯器并沒有這項功能，也沒有哪款常見的編譯器會生成一個以上的純函數實例，除非……

除非我們“騙騙”編譯器。這個過程跟單態化非常相似：傳說有一種跟 C++ 一樣古老的絕技，能根據接收到的回調類型對數據進行參數化。如果大家用過 C++ 代碼庫，就會注意到其中接受回調的函數往往是泛型的，也就是將函數回調的類型當作參數。在對封閉函數進行單態化時，該函數調用的特定回調會被替換為 IR，這樣就無所謂內不內聯了——特別是在純函數（即不捕捉任何參數回調）的情況下。依托于這種可靠的優化方法，lmabda 與模板的組合已經成為現代 C++ 中最高效的抽象基礎，也給 Go 這類本身比較僵化的語言帶來了更強的表達力，在無需引入新語法或運動時開銷的前提下、實現了對迭代及其他函數構造的支持。

問題在于：我們在 Go 里能實現相同的效果嗎？或者說，能根據回調函數對函數進行參數化嗎？雖然我能找到的一切泛型文檔中都沒提過，但答案仍然是肯定的。我們可以將迭代器函數的簽名寫成以下形式，它仍然可以順利編譯并運行：



沒錯，我們可以使用函數簽名作為泛型約束，這種約束不一定得是接口，請大家牢記這點。至于這次優化的結果可能大家已經猜到了，基本沒任何效果。實例化泛型函數的 shape 并不特定于我們的回調，而是 func(rune) 回調的泛型 shape，同樣不支持任何類型的內聯。

所以，這說明函數回不回調其實無所謂？不完全是。事實證明，自 1.0 版本以來，Go 編譯器的內聯功能已經相當強大。只要泛型不來礙事，它其實完全可以實現更好的優化效果。

來看下面這個例子：假定我們正開發一個庫，用于為 Go 添加函數構造。為什么要這么干？我也不太清楚，但很多人就是這么干的，可能是為了趕時髦吧。總之，我們還是從簡單的用例出來：設置一個“Map”函數，它對切片內的每個元素進行一次回調，再把結果存儲在適當位置。

在討論泛型 map 之前，我們先來看看被硬編碼為 int 切片形式的 MapInt，思考 Go 編譯器能用這段代碼做點什么。事實證明，能做的很多：MapInt 的程序集看起來很棒。從示例中，可以看到主 IntMapTest 中沒有 CALL：我們從加載全局 input1 切片直接推進到進行迭代，而且只需要使用一條指令就能執行映射操作（在本示例中為簡單乘法）。很明顯，此函數已經完全扁平化，而且 MapInt 與 IntMapTest 內部的匿名回調在編譯代碼中都不見蹤影。

只要大家過去十年來一直關注 Go 的性能演變，就能感受到這具有多大的現實意義！

例子中的這個簡單 MapInt 函數，實際上代表著 Go 編譯器中一個啟發式的內聯壓力測試：它不是葉子函數（因為它會在其中調用另一個函數），而且包含一個帶有范圍的 for 循環。這兩個細節，讓該函數無法針對截至目前的任何一個 Go 版本進行優化。棧中內聯功能直到 Go 1.10 版本才趨于穩定，而對包含循環的函數進行內聯則是個已經持續存在六年多的難題。事實上，Go 1.18 是第一個能夠對范圍循環進行內聯的版本；所以哪怕再提前幾個月，MapInt 的編譯結果都會大不相同。

這對 Go 編譯器的代碼生成能力確實意義重大，所以我們得繼續觀察這個函數的泛型實現，但其實并不存在這樣的實現。由于棧中內聯，MapAny 的主體已經在其父函數中完成了內聯。所以現在位于泛型 shape 后的實際回調已經以獨立函數的形式生成，而且必須在循環的每一次迭代中進行顯式調用。

不過別擔心，不妨試試我們剛剛討論過的模式，也就是對回調的類型進行參數化。秘密就在這里！我們又得到了一個完全扁平化的函數，而且這可不是魔術。內聯畢竟是一種啟發式方法。在這個特定示例中，我們用正確的方式實現了這種啟發式方法。因為我們的 MapAny 非常簡單，所以整個主體都可以內聯。要想進一步測試，我們就能為泛型函數的 shape 添加更多特異性。只要對函數的回調不等于對泛型 shape 的回調，而是 func(rune) 回調的一個單態化實例，那 Go 編譯器就能展開整個調用。

到這里，大家猜到我想做什么了嗎？在這個示例中，內聯函數體其實是一種非常特殊的單態化形式，這種特殊性體現在它的實例化 shape 本質上就是一個完整的單態：因為封閉函數不是泛型，所以它就只能是單態。在這種代碼可以完全單態化的情況下，Go 編譯器將帶來非常有趣的優化效果。

總體來講，如果大家正在編寫使用回調的函數式幫助器，例如迭代器或者 Monad，那最好能根據回調類型進行參數化。當且僅當幫助器本身足夠簡單且可以完全內聯時，這步參數化操作將使 inliner 完全扁平化該調用，這也就是我們需要的函數式幫助器。但如果大家的幫助器不夠簡單、無法內聯，那么參數化將毫無意義。因為實例化的泛型 shape 會太過粗糙，無法實現任何優化。

最后需要強調的是，盡管這個完整的單態化示例在很多情況下可能并不可靠，但它確實給我們指明了性能優化的新方向：Go 編譯器已經非常擅長內聯，只要能把它指向非常具體的代碼實例，它就能生成極好的匯編結果。Go 編譯器自身已經包含大量優化選項，只待泛型實現給它一點發揮的空間。

總? ? 結

這次實驗真的很有趣，希望大家跟我一樣樂在其中。下面，讓我們用一份簡短的清單結束這篇文章，看看 Go 1.18 中那些關于性能優化與泛型實現的“要”和“不要”：

• 要盡量使用 ByteSeq 約束對，同時使用 string 與 []byte 的相同方法進行重復部分的刪除。由此生成的 shape 實例將非常接近于手動編寫兩個幾乎相同的函數。

• 要在數據結構中使用泛型，這也是泛型目前最理想的用例。以往使用 interface{}實現的泛型數據結構太過復雜、也不符合大多數人的思維習慣。只要刪除類型斷言、以類型安全的方式存儲未裝箱類型，就能讓這些數據結構更易用、運行更快。

• 要盡量通過回調類型對函數幫助器進行參數化。在某些情況下，Go 編譯器有可能將其展平。

• 不要試圖用泛型對方法調用進行去虛擬化或內聯。這樣沒用，因為所有指針類型都擁有同一個可傳遞至泛型函數的 shape；相關方法信息放置在運行時字典當中。

• 在任何情況下，都不要將接口傳遞給泛型函數。因為 shape 實例化更適應接口（而非去虛擬化），所以我們需要添加額外的虛擬化層，由該層提供一份用于查找各方法調用的全局 hash 表。如果您的項目對性能比較敏感，請保證只在泛型中使用指針、不用接口。

• 不要重寫基于接口的 API 來使用泛型。受制于當前實現，只要繼續使用接口，所有使用非空接口的代碼都將更簡單、并帶來更可預測的性能。在方法調用方面，泛型會將指針轉化為兩次間接接口，再把接口轉換成……總之，特別麻煩、也毫無必要。

• 不要失望，畢竟 Go 泛型在語言設計上沒有任何技術限制，所以未來的內聯或去虛擬化方法調用一定會迎來更好用的單態化實現。

說了這么多，可能期待著能在 Go 1.18 中利用泛型優化代碼性能的朋友們已經大失所望。確實很遺憾，至少在 1.18 的泛型實現中，大多數只會讓代碼運行速度變得更慢。但也有一些反例，告訴我們希望還會出現。不管大家是不是把 Go 看作“面向系統”語言，都很難理解為什么要把運行時字典塞進編譯語言技術實現。雖然 Go 編譯器的復雜度不高，但它自 1.0 版本以來的代碼生成質量一直在穩步提高，而且到現在為止始終保持著這種改善勢頭。

從 Go 1.18 說明文檔中關于完全單態化的風險來看，選擇使用字典來實現泛型的理由，似乎是代碼單態化的速度很慢。但這又帶來了新問題：真的嗎？既然從來就沒有過 Go 代碼單態化方案，怎么判斷它很慢？

我總覺得這種復雜的技術權衡背后，是有某種頑固的誤導性假設在作祟。這種假設在開發者腦袋里普遍存在，例如“單態 C++ 代碼就很慢”。但還是那個問題：真的嗎？有多少 C++ 編譯開銷真的來自單態化，又有多少是代碼編寫者的問題？另外，單態化代碼難道沒有優化方案嗎？C++ 模板實例化性能不佳，所以 Go 編譯器就肯定性能不佳？Go 編譯器優化通道較少、模塊系統相對簡單，難道不能防止大量冗余代碼的產生？在編譯 Kubernetes 或者 Vitess 這類大型 Go 項目時，單態化到底會帶來怎樣的性能影響？這些都是沒有定論的問題，最好別粗暴做出假設。

更靠譜的辦法自然就是把握當下、盡快測試。同樣地，我們也可以測量 stenciling+ 字典在現實應用代碼中的性能影響，這就是本次分析的目標。從結果來看，為了幫 Go 編譯器省下一點開銷，我們好像把負擔都轉嫁給程序本身了吧。

綜合目前的結論，特別是現有泛型實現對代碼運行性能造成的真實影響，我希望 Go 團隊能重新審視“用運行時字典縮短編譯時間”這套方案，在未來的 Go 版本中使用更積極的單態化實現。必須承認，向 Go 中引入泛型確實是個艱難的任務。從功能設計層面看，這是野心勃勃的一步，但也把語言復雜性推向了新的高點。如果未來能出現一種適應大部分開發場景、沒有運行時開銷，不僅能夠實現參數多態性、還能帶來深層次優化的實現方案，相信整個 Go 社區都將從中大大受益。

原文鏈接：

https://planetscale.com/blog/generics-can-make-your-go-code-slower

Qt 的辛酸發展史

Facebook開發者 4 種首選語言！

簡單軟件架構的一些好處

好看好玩又搞怪的頭像+壁紙

點個在看少個 bug?👇

總結

以上是生活随笔為你收集整理的泛型会让你的 Go 代码运行变慢的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。