C# 反射效能深度分析：實測數據揭示 20-350 倍效能差距

反射是 C# 強大的動態特性，但效能代價有多大？本文透過實際基準測試，量化反射在物件建構、方法呼叫、靜態方法呼叫三大場景的效能損耗，並分析 IL 層面的根本原因。

測試環境與基準類別

public class CTester
{
    private double _value;

    public CTester() => _value = 10;

    public void TestMethod() => _value = (_value - 0.0001) * 1.0001;

    public double GetValue() => _value;
}

測試迴圈：1,000 外層 × 100 內層 = 100,000 次操作

測試一：物件建構效能

關鍵發現：Type.GetType() 重複呼叫是主要效能殺手。快取 Type 物件可大幅改善。

測試二：實例方法呼叫效能

測試三：靜態方法呼叫效能

IL 層面根因分析

使用 ILDASM 對比 IL 碼發現，直接呼叫產生 callvirt 指令，而反射呼叫轉為：

callvirt instance object [mscorlib]System.Type::InvokeMember(
    string, 
    valuetype [mscorlib]System.Reflection.BindingFlags,
    class [mscorlib]System.Reflection.Binder,
    object,
    object[]
)

核心開銷來源：

1. 晚期繫結解析：執行期解析方法名稱、參數型別、繫結旗標
2. 參數封送：建立 object[] 陣列、裝箱/拆箱值型別
3. 安全性檢查：權限驗證、存取層級檢查
4. 委派調用開銷：動態建立委派或使用內部調用器

效能優化策略

委派快取範例

// 一次性建立委派，後續重複使用
var methodInfo = typeof(CTester).GetMethod("TestMethod");
var instance = Expression.Parameter(typeof(CTester), "instance");
var call = Expression.Call(instance, methodInfo);
var fastInvoker = Expression.Lambda>(call, instance).Compile();

// 使用
fastInvoker(tester); // 效能接近直接呼叫

結論與建議

• 反射確實存在顯著效能代價（20x - 3500x），不宜用於高頻熱路徑
• 快取反射物件是最低成本的優化，必須實施
• 高頻動態調用場景請改用委派快取或Expression Trees
• 框架/庫開發者應在設計時權衡靈活度與效能，提供非反射替代方案
• 應用層業務邏輯避免濫用反射，優先使用介面、泛型、依賴注入等靜態多型機制

反射是利器，但請在正確的場合、以正確的方式使用它。