Effective C# 原則 31：撰寫小而簡單的函式，讓 JIT 編譯器發揮最大效能

手動優化往往適得其反

許多開發者習慣寫龐大函式以「減少呼叫開銷」，但在 .NET 中這會阻礙 JIT 編譯器最佳化，反而產生更慢代碼。最佳策略：以最清晰方式表達演算法，其餘交給 JIT。

JIT 編譯器逐函式編譯機制

• CLR 於執行期逐函式呼叫 JIT 編譯 IL 為機器碼。
• 從未被呼叫的函式不會被編譯。
• 龐大函式首次呼叫時，所有分支皆被編譯，即使僅執行單一路徑，造成浪費。

拆分為小函式後，JIT 僅編譯實際執行路徑：

// 原始：巨大函式，雙分支皆編譯
public string BuildMsg(bool takeFirstPath) { ... }

// 優化：拆分小函式，JIT 按需編譯
public string BuildMsg(bool takeFirstPath) => takeFirstPath ? FirstPath() : SecondPath();

小函式的三大 JIT 最佳化優勢

1. 按需編譯：避免編譯未使用路徑，減少啟動延遲與記憶體佔用。
2. 暫存器分配：簡單控制流程、少區域變數，利於 JIT 將熱點變數置於 CPU 暫存器。
3. 內聯候選：極小函式（如屬性存取子）極易被 JIT 內聯，消除呼叫開銷。虛擬函式、含 try/catch 的函式無法內聯。

實務準則

• 函式保持單一職責、控制流程簡單。
• 重載關係運算子（<, > 等）委派給型別安全的 CompareTo。
• 信任 C# 編譯器與 JIT 的雙層最佳化管道，專注於演算法清晰表達。

記住： 代碼經歷「C# 編譯器 → IL」與「JIT → 機器碼」兩階段編譯。小而簡單的函式讓 JIT 輕鬆分期編譯、內聯、暫存器最佳化，打造高效執行碼。