Hackの深淵へようこそ。私はHHVMのコア開発に携わる者として、皆さんに「魔法のように見える」Hackのパフォーマンスの裏側を覗いてもらおうと思います。
今回は、多くのエンジニアが「なんとなく」使っている`try-catch`ブロックのコストについて深掘りします。なぜ、安易な例外処理がアプリケーションを鈍らせるのか。JIT（Just-In-Time）コンパイラが裏側で何をしているのか、その真実を解き明かしましょう。
—
1. JITコンパイルにおける「例外」の正体
まず、皆さんが書く `try-catch` が、マシン語の世界でどう扱われているか想像してみてください。
実は、HHVMのJITエンジンは、「正常系」をいかに高速に走らせるかに全てを賭けています。JITはコードを実行しながらプロファイリングを行い、ホットなパスを最適化します。その際、`try-catch` があると、JITは「ここには爆弾（例外）が埋まっているかもしれない」という境界線を引かなければなりません。
正常系 vs 例外発生時の挙動
- 正常系（Happy Path）: JITは例外が発生しない前提で、レジスタをフル活用して最高速のコードを生成します。このとき `try` ブロックは、ほとんどオーバーヘッドを生みません。
- 例外発生時（Sad Path）: 例外がスローされた瞬間、制御はJITが生成した最適化コードから離れ、「ランタイムの例外ハンドラ（C++層）」へと強制的にジャンプします。ここでスタックアンワインド（呼び出し履歴の巻き戻し）が発生し、非常に重い処理が走ります。
つまり、`try-catch` 自体のコストは低いのですが、「例外を投げる」という行為そのものが、HHVMの最適化を無効化するほどの劇薬であることを理解しておく必要があります。
—
2. 現場で使える「例外」の設計指針
「例外は制御フローの手段ではない」というのはHackでも鉄則ですが、パフォーマンスの観点から具体例を見てみましょう。
悪い例：ループ内での例外使用
// 非常に危険！ループ内での例外はHHVMのJIT最適化を破壊します
foreach ($items as $item) {
try {
$this->process($item);
} catch (Exception $e) {
// 例外が発生するたびにスタックトレースが生成され、
// JITの最適化パスが中断・再構築されます。
continue;
}
}
良い例：結果型（Resultパターン）の活用
Hackには強力な静的型システムがあるのですから、例外を投げるのではなく、状態を型で表現しましょう。
// 成功か失敗かを型として返す（Eitherパターン的なアプローチ）
type ProcessResult = shape(‘success’ => bool, ‘error’ => ?string);
function safeProcess(mixed $item): ProcessResult {
if (!$this->isValid($item)) {
return shape(‘success’ => false, ‘error’ => ‘Invalid data’);
}
return shape(‘success’ => true, ‘error’ => null);
}
—
3. なぜ `try-catch` を「最小」にすべきなのか？
HHVMのアーキテクチャでは、`try` ブロックがネストしたり、広範囲にわたったりすると、JITは「例外発生時に復帰すべき場所（Landing Pad）」を大量に管理しなければなりません。
これを図解するとこうなります：
- 理想的なコード: [直線的な処理] -> [高速なCPU命令列]
- 例外だらけのコード: [処理A] -> [例外チェック分岐] -> [処理B] -> [例外チェック分岐]…
この「例外チェック」が、CPUのパイプライン予測を乱します。特に高頻度で実行される関数（ホットスポット）において、`try-catch` で囲まれた範囲が広いと、JITがその領域を「最適化不可能」と判断し、本来の速度を出せなくなることがあります。
—
4. 今日から意識すべき「極限の知見」
Hackを掌握するために、以下の3点を意識してください。
1. 「例外は異常事態にのみ使う」という原点: 制御フローの分岐に `try-catch` を使うのは、言語のアーキテクチャに対する敗北です。
2. スコープを極限まで狭める: どうしても例外が必要な場合、`try` ブロックの中には「例外をスローする可能性のある最小限のコード」だけを置いてください。余計な処理を入れないだけで、JITの最適化効率は劇的に向上します。
3. 型システムを武器にする: 失敗する可能性がある処理は、`?T` 型や、独自のResult型を返し、呼び出し側でチェックするように設計します。これが、Hackの静的型システムを最も活かす道です。
—
まとめ
HHVMのJITは、あなたが書いたコードの「裏側の意図」を読み取ろうと必死です。`try-catch` を闇雲に配置することは、そのJITに対して「ここから先は先読みするな」という命令を出しているのと同じなのです。
ここをクリアすれば、皆さんはもうただのプログラマーではなく、「HHVMのJITと対話できるエンジニア」の入り口に立っています。パフォーマンスの細部までをコントロールする、その意識こそがHackの醍醐味です。
さあ、次はどんな最適化に挑戦しましょうか？また次の講義でお会いしましょう。