代碼執行效率深度解析（二）：編譯器優化的威力與誤區

上篇確立演算法為效能關鍵，本文揭示編譯器優化如何重塑代碼執行面貌。高級語言代碼長短、變數多寡與機器碼效能關係微弱，盲目手動微優化往往適得其反。

尾遞歸優化：F# 編譯器的魔法

遞歸求和單向鏈表，直觀寫法空間複雜度 O(n) (調用棧累積)：

let rec sum ls =
  match ls with
  | [] -> 0
  | x::xs -> x + sum xs

引入累加器參數實現尾遞歸：

let sum ls =
  let rec sum' ls acc =
    match ls with
    | [] -> acc
    | x::xs -> sum' xs (acc + x)
  sum' ls 0

F# 編譯器自動將尾遞歸轉換為迴圈（IL 反編譯為 C# 可見）：

public override int Invoke(FSharpList ls, int acc) {
  while (true) {
    var list = ls;
    if (!(list is FSharpList._Cons)) return acc;
    var cons = (FSharpList._Cons)list;
    ls = cons.get_Tail();
    acc += cons.get_Head();
  }
}

同樣是遞歸寫法，編譯器優化後空間複雜度降為 O(1)，效能媲美手寫迴圈。

編譯器擅長的機械優化

• 常量摺疊：編譯期計算常量表達式（數值、字串連接）
• 內聯：消除呼叫開銷，啟用後續優化機會
• 迴圈展開：減少分支預測失誤，增加指令級並行
• 冗餘消除：刪除無副作用的死代碼、公共子表達式
• 指令排程：調整指令順序利用 CPU 流水線/超純量

這些優化由編譯器系統性、全域性完成，人工極難超越。

語言特性影響編譯器優化上限

C/C++ 指標別名問題限制優化：

for (int i=0; i<20000; i++)
  for (int j=0; j<20000; j++)
    x[i][j] = y[i-2][j+1] * y[i+1][j-2];

編譯器無法確定 x 與 y 是否重疊，被迫保守生成代碼。Fortran `restrict` / C99 `restrict` / C# 陣列無別名，允許激進向量化。OCaml 編譯器甚至能識別下標關係、合併迴圈、提升不變量，超越 C/C++ 20%+。

實測數據：OCaml vs C/C++/Java

最長公共子串問題，長度 2000 陣列：

JIT 編譯器利用運行時資訊（熱點、型別專精化）超越靜態編譯。

核心啟示

1. 代碼字面長短 ≠ 效能：Haskell 快排極短但因不可變鏈表慢於 C# 陣列版。
2. 手動微優化（少變數、少判斷）多為無效甚至有害：干擾編譯器分析，降低可讀性。
3. 迎合編譯器優化模式：尾遞歸、避免別名、單一職責函數利於內聯。
4. Profiling 是唯一真理：靜態分析不可靠，動態測量熱點再優化。

下篇將探討「演算法一致、編譯器不優化」前提下的硬體層面效能關鍵——快取與局部性。