C++26 反射的真實成本：列舉轉字串轉換的基準測試

將列舉（enumeration）轉換為字串通常被認為是反射的「Hello World」。雖然看似簡單，但對於專業 C++ 專案中的日誌記錄、序列化和除錯來說，這是一個無處不在的需求。隨著 GCC 16 的正式發布，開發者現在有了一個具體的機會來衡量 C++26 反射與傳統替代方案的效能表現。

由 Vittorio Romeo 進行的最新基準測試強調了一個關鍵區別：使用反射的成本不在於反射演算法本身，而是在於支持它所需的基礎設施。

比較三種實作策略

為了確定編譯時的影響，我們對三種不同的列舉轉字串轉換方法進行了基準測試：

1. C++26 反射

使用 <meta> 標頭檔，這種方法最符合人體工學。它不需要任何巨集，且對於任何列舉類型（無論其結構如何）都有效。

template <typename T>
    requires std::is_enum_v<T>
constexpr std::string_view to_enum_string(T val)
{
    template for (constexpr auto e : 
        std::define_static_array(std::meta::enumerators_of(^^T)))
    {
        if (val == [:e:])
            return std::meta::identifier_of(e);
    }
    return "<unknown>";
}

2. enchantum (C++17)

此函式庫使用 __PRETTY_FUNCTION__ 解析技巧來實現類似反射的行為，而不需要在呼叫端使用反射旗標或巨集。

3. X-Macros (預處理器方法)

這種 C 風格的解決方案使用單個巨集列表來展開成列舉定義和用於字串轉換的 switch 陳述式。這是最「底層」的方法，如果使用 const char* 而非 std::string_view，通常可以實現零標準函式庫包含。

基準測試結果

基準測試是在 13th Gen i9-13900K 上使用 GCC 16.1.1 進行的。結果顯示，隨著列舉成員（N）增加，每個翻譯單元（TU）的總編譯時間呈現出顯著的差異。

N X-macro (const char*) X-macro (string_view) enchantum Reflection
Baseline 25.7 ms 25.7 ms 25.8 ms 25.7 ms
Header only 25.7 ms 136.0 ms 147.1 ms 180.8 ms
4 26.6 ms 137.6 ms 170.6 ms 186.7 ms
1024 54.7 ms 204.5 ms 272.0 ms 255.0 ms

規模化關鍵發現

  • 標頭檔稅收： 最顯著的發現是，包含 <meta> 的成本比基準值高出約 155 ms 每 TU。
  • 演算法效率： 一旦包含了標頭檔，反射演算法非常快，其規模擴展速度大約為 0.07 ms 每列舉成員，這與 X-macro 版本中手寫的 switch 幾乎相同。
  • enchantum 規模化： 與其他方法不同，enchantum 的擴展與配置的掃描範圍有關，而非列舉成員的數量，這使得它對於小型列舉來說相對昂貴。

優化反射效能

鑑於 <meta> 標頭檔的高昂成本，本研究探索了使用預編譯標頭檔（PCH）和 C++20 Modules 來減輕開銷。

  • PCH (勝出者)： 預編譯 <meta> 導致了 2.3 倍的加速，將 4 個成員的列舉編譯時間從 187 ms 降至 81 ms。使用 PCH 後，反射比 enchantum 和 string_view 版本的 X-macro 都更快。
  • Modules (令人驚訝的結果)： 令人驚訝的是，在 GCC 16 中，C++20 modules 實際上使編譯速度慢了約 2.2 倍，與單純包含標頭檔相比。這表明目前 GCC 16 的實作中，模組載入尚未優化到 PCH 的程度。

實際應用影響

雖然每個 TU 增加幾百毫秒看似微不足道，但其影響會隨著專案規模線性擴展。在一個擁有 500 個 TU 的程式碼庫中，X-macro 方法（約 13 秒）與反射方法（約 94 秒）之間的差異，可能就是快速增量編譯與令人沮喪的緩慢編譯之間的區別。

開發者建議

  1. 優先使用 PCH 而非 Modules： 目前，如果你使用的是 GCC 16，請使用 PCH 來處理 <meta>。
  2. 最小化標頭檔暴露： 將列舉轉字串的標頭檔盡可能放在包含圖譜（include graph）的底層，以避免傳遞性包含的開銷。
  3. 對於極致效能，堅持使用 X-Macros： 在編譯時間極其關鍵的專案中（例如，編譯時間需低於 10 秒），儘管缺乏人體工學，X-macros 仍是更優的選擇。
  4. 函式庫作者請注意： 避免透過公開標頭檔暴露反射功能，因為這會強迫每個使用者都必須支付 <meta> 標頭檔稅收。

社群觀點

這項基準測試引發了開發者之間關於人體工學與效能之間的權衡討論。一些人指出，雖然反射是一個強大的工具，但使用外部程式碼生成（一個獨立程式來處理原始碼）的「C 風格」方法仍然是一種高度可除錯且高效的替代方案。

其他人則質疑將這些結果推廣到其他編譯器是有效的，並指出隨著 Clang 的 C++26 反射實作變得成熟，效能特性可能會顯著不同。正如作者所言：

C++26 反射的成本不在於反射本身。而在於 <meta>。

Sources