パフォーマンス・サイズ影響¶

オーバーヘッドはパスと関数複雑度により変動します。下記は代表的なモバイルゲームモジュール (約200関数、Cortex-A55) での実測値です。

パス	コードサイズ増加	実行時オーバーヘッド	メモ
`str`	+5 – 15%	<1%	初使用時に復号後ゼロ化、ホット文字列はキャッシュ
`str-aes`	+8 – 20%	<1%	AES-128-CTR; キャッシュ動作は `str` と同様
`fla`	+40 – 120% / 関数	タイトループで 5 – 15%	小さな BB が多い関数で最悪
`bcf`	+20 – 50% BBs	<2%	死コード — 一度も実行されない
`sub`	+10 – 30% / 関数	算術中心コードで 3 – 8%	`--kagura-sub-iter=1` (デフォルト) を推奨
`mvo`	+15 – 40% / 関数	alloca が多いコードで 5 – 12%	`pe` と併用で最大効果
`vm`	−30 to +200%	10 – 50× の減速	小さく呼び出し頻度の低い関数 (ライセンスチェック、暗号初期化) に限定
`anti-debug`	+<1%	無視可能 (起動時のみ)	初期化時の一度きりチェック
`bbcheck`	+10 – 20%	2 – 5%	BB 単位オーバーヘッド; セキュリティクリティカル関数のみで使用

推奨¶

BALANCED 強度プロファイルをグローバルに適用し、最も機密度の高い10〜20関数だけ STRONG または kagura_vm でアノテーションすること。これで中央値オーバーヘッドを 5% 未満に抑えつつ、クリティカルパスでの保護を最大化できます。

// ホットパス — デフォルトの BALANCED で十分
int game_tick(GameState *s) { ... }

// セキュリティクリティカル — VM 仮想化 (遅いが許容)
__attribute__((annotate("kagura_vm")))
int verify_session_token(const char *t) { ... }