C++26 リフレクションの真のコスト：EnumからStringへの変換のベンチマーク
列挙型（enumeration）を文字列に変換することは、リフレクションの「Hello World」としばしば見なされます。一見単純に見えますが、プロフェッショナルなC++プロジェクトにおけるロギング、シリアライゼーション、デバッグにおいて、至る所で見られる要件です。GCC 16の公式リリースに伴い、コミュニティは現実的なシナリオにおいてC++26リフレクションの実際のコストを測定する具体的な手段を手に入れました。
Vittorio Romeoによって実施された最近のベンチマークは、驚くべき事実を明らかにしています。リフレクションの「遅さ」の認識は、リフレクションのアルゴリズム自体によるものではなく、それをサポートするために必要な標準ライブラリヘッダーのオーバーヘッドによるものです。
3つの実装戦略の比較
トレードオフを理解するために、enumからstringへの変換に対する3つの異なるアプローチがベンチマークされました：C++26リフレクション、enchantumライブラリ（C++17）、および伝統的なCスタイルのX-macroです。
1. C++26 Reflection
これは最も慣用的で使いやすいアプローチです。マクロを必要とせず、宣言箇所でのボイラープレートなしに、あらゆるenumに対して動作します。<meta>を使用することで、型の列挙子を反復処理し、識別子名を返します。
2. Enchantum (C++17)
enchantumは、C++17においてリフレクションのような動作を実現するために、__PRETTY_FUNCTION__のパース手法を用いるヘッダーオンリーライブラリです。呼び出し側でのマクロは回避できますが、設定可能な値の範囲をスキャンして一致するものを見つける方法で動作します。
3. X-Macros (Preprocessor)
「古い方法」は、マクロ内で列挙子を一度だけリストアップし、そのマクロをenumの定義と、文字列変換のためのswitch文の両方に展開することを含みます。これは最も手動なアプローチですが、複雑なテンプレートメタプログラミングを回避できます。
ベンチマーク結果
GCC 16上で、様々なenumのサイズ（4から1024個の列挙子）にわたってテストを行った結果、コンパイル時間のパフォーマンスに顕著な差が見られました。
トランスレーションユニット（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 |
| 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 |
主な発見
- ヘッダー税 (The Header Tax): 最も重要な発見は「ヘッダー税」です。実際にリフレクションが実行されているかどうかにかかわらず、
<meta>を含めるだけで、ベースラインに対して約155 ms per TUのコストがかかります。対照的に、const char*を使用したX-macroバリアントは、オーバーヘッドがほぼゼロです。 - アルゴリズムの効率性: ヘッダーが含まれた後は、リフレクションのアルゴリズムは驚くほど高速です。列挙子1つあたり約0.07 msのスケールで動作し、これはX-macro版の自作
switch文（~0.06 ms）とほぼ同等です。 - Enchantumのスケール性:
enchantumは固定の範囲をスキャンするため、そのコストは列挙子の数に比例して線形に増加しません。4つの要素を持つenumは64個の要素を持つものとほぼ同じコストがかかり、リフレクションと比較して非常に小さなenumに対しては効率が低くなります。
オーバーヘッドの最適化：PCH vs. Modules
#include <meta>の高コストを考慮し、本研究では、プリコンパイル済みヘッダー（PCH）またはC++20 Modulesがコストを軽減できるかどうかを調査しました。
- PCH (勝者): 必要なヘッダーをプリコンパイルすることで、2.3倍の高速化を実現し、小さなenumのコンパイル時間を187 msから81 msに短縮しました。PCHを使用すると、リフレクションは
enchantumとstring_viewを使用したX-macroバリアントの両方よりも高速になります。 - Modules (驚きの結果): 驚くべきことに、GCC 16におけるC++20 modulesは、コンパイルを実際には約2.2倍遅くしました。これは、おそらくGCCが現在
stdモジュールをヘッダーユニットのラッパーとしてどのように扱うかという、一時的な実装の詳細によるものです。
実社会への影響
1 TUあたりの数百ミリ秒は無視できるように思えるかもしれませんが、その影響は大規模なコードベース全体で線形にスケールします。500個のトランスレーションユニットを持つプロジェクトでは：
- X-macro (
const char*): 合計約13秒のCPU時間。 - Reflection: 合計約94秒のCPU時間。
この差は、15秒未満で終わるクリーンビルドと、1分半以上かかるビルドが分かれる境界線になり得ます。コンパイル時間に非常に敏感なプロジェクトの開発者にとって、X-macroは依然として最もパフォーマンスの高い選択肢です。
戦略的な推奨事項
C++26リフレクションを採用するチームは、ビルド時間を最小限に抑えるために、以下の戦略を推奨します：
- ModulesよりもPCHを優先する: モジュール実装が成熟するまでは、
<meta>のためのPCHを使用することで、ヘッダー税を大幅に削減できます。 - インクルードの深さを最小限にする: 公開ヘッダーにリフレクションヘッダーを含めることは避けてください。インクルードグラフの可能な限り深い位置に配置し、理想的には
.cppファイルに限定することをお勧めします。 - ライブラリ開発者は注意が必要: 公開ライブラリのヘッダーにリフレクションを露出させることは慎大家重、すべての利用者のTUが
<meta>税を支払うことを強いることになります。
コミュニティの視点
これらのベンチマークに関する議論は、C++開発の未来に関するいくつかの興味深い点を提起しています：
"C++26リフレクションのコストは、リフレクションそのものではなく、
<meta>です。"
一部の開発者は、リフレクションが強力なツールである一方、メタプログラミングへの執着は、より単純な外部コード生成（例：Pythonスクリプトやlibclangを使用）によって解決できる複雑さを招くことが多いと主張しています。他の開発者は、C++26リフレクションの構文が「外来」的な見た目をしており、古い標準に慣れた人々にとって学習曲線が急である可能性があると指摘しています。最終的には、多くの人にとっての目標は、より単純なstd::to_string(enum)が実現されることで、これら複雑な回避策を必要としないようにすることです。