代碼執行效率深度解析（一）：演算法才是核心，拒絕「代碼越短越快」迷思

網路流傳「程式碼越短效能越高」的觀點，聲稱減少語句、變數、判斷即是優化。這種片面認識極具誤導性。本文從演算法複雜度、實際資料特性、編譯器現實三個維度，系統駁斥此迷思並建立正確效能觀。

「簡短=高效」為何不成立？

前提條件不存在：
1. 代碼非純順序執行（存在迴圈/遞歸），短代碼可能執行更多次。
2. 每行代碼開銷差異巨大（i++ vs 方法呼叫 vs I/O）。
高級語言不直接映射機器指令，**靜態代碼長度無法預測動態執行路徑**。

經典反例：冒泡排序 vs 快速排序

// 冒泡排序：代碼簡短 ~20 行，O(n²)
public void BubbleSort(int[] a) {
  for (int i = a.Length-1; i >= 0; i--)
    for (int j = 1; j <= i; j++)
      if (a[j-1] > a[j]) Swap(ref a[j-1], ref a[j]);
}

// 快速排序：代碼較長 ~50 行，平均 O(n log n)
public void QuickSort(int[] a) => QuickSortInternal(a, 0, a.Length);
private void QuickSortInternal(int[] a, int l, int r) {
  if (l >= r) return;
  int p = Partition(a, l, r);
  QuickSortInternal(a, l, p-1);
  QuickSortInternal(a, p+1, r);
}

快排雖代碼較長、常數因子較大，但大數據量下**演算法複雜度優勢碾壓**冒泡。小數據量時快排常切換至插入排序（混合策略）。

Haskell 快排：代碼極短但非最快

qsort [] = []
qsort (x:xs) = qsort (filter (< x) xs) ++ [x] ++ qsort (filter (>= x) xs)

僅 2 行，但基於不可變鏈表，記憶體分配/複製開銷大，實際效能不如 C# 陣列原地排序。資料結構選擇往往比代碼長短更關鍵。

理論複雜度 ≠ 實際效能

• 資料規模有限：O(n log n) 常數大，小 n 時 O(n²) 可能更快。
• 資料特性：近乎有序陣列，冒泡/插入排序 O(n) 完勝快排。
• 空間換時間陷阱：大量記憶體導致頁面交換，反而拖慢速度。
• 物件分配開銷：某些場景每次新建物件比物件池更快（Gen 0 GC 極快）。

**選擇演算法必須結合具體業務場景測試，而非迷信理論複雜度。**

微優化的邊際效應與風險

在演算法確定前提下，手動減少賦值/判斷：
- 效能增益通常 < 1%（編譯器已處理）
- 犧牲可讀性、可維護性
- 可能破壞編譯器優化假設（如 SSA 形式）

清晰、正確 > 微優化。除非 Profiling 確認熱點且證實有效，否則不應進行。

建立正確效能工程觀

1. 演算法與資料結構選擇：數量級優化（O(n²)→O(n log n)）。
2. 架構層面：快取策略、非同步/並行、I/O 批次、資料庫索引。
3. 編譯器/運行時優化：釋放友善代碼模式（尾遞歸、避免別名、內聯友善）。
4. 硬體感知：快取局部性、向量化、分支預測、NUMA 感知。
5. 持續 Profiling：針對真實熱點精準優化，避免過早優化。

系列下篇將深入編譯器優化機制，揭示高級語言與機器碼的真實關係。