こんにちは。普段はPHPのフレームワークを使いこなし、「なんだか最近、アプリのレイテンシーが気になるな」「もっとスケールさせたいけれど、どこがボトルネックなんだろう」と立ち止まっているエンジニアの皆さんへ。
私たちは普段、何気なく `strlen()` や `array_map()` といったPHPの内部関数（Internal Functions）を呼び出し、自分たちで書いたユーザー定義関数（User-defined Functions）を組み合わせながらアプリケーションを構築していますよね。
でも、ちょっと立ち止まって考えてみてください。
「PHPの関数呼び出しって、内部のZend VM（Zend Engine）で実際には何が起きているんだろう？」
「内部関数とユーザー定義関数で、実行コストにどんな差があるんだろう？」
今回は、私と一緒にPHPの心臓部であるZend VMのレイヤまで降りて、関数呼び出しの裏側を覗いてみませんか？ここを理解すると、コードの書き方が変わり、パフォーマンスチューニングの引き出しが劇的に増えますよ。
—
1. Zend VMの視点：関数呼び出しの「重み」を知る
私たちが書いたPHPコードは、パーサによって抽象構文木（AST）に変換され、最終的にZend VMが解釈・実行するためのオペコード（Opcode）へとコンパイルされます。
ここで、PHPが1リクエストを処理する際、関数が呼ばれるたびにZend VMの内部では何が行われているのでしょうか？答えは「スタックフレーム（Zend Execution Stack Frame）の構築」です。
ユーザー定義関数が呼ばれるときの手間
私たちが `function calculate($a, $b) { … }` のようなユーザー定義関数を呼び出すと、Zend VMは以下のような重厚な処理を実行します。
1. 新しい実行スコープの割り当て:
現在の関数コンテキスト（`_zend_execute_data`）から、新しい関数のためのメモリ空間を確保します。
2. 引数の評価と受け渡し:
呼び出し元から渡された引数を、新しいスタックフレームのローカル変数シンボルテーブル（またはスロット）へマッピングします。
3. シンボルテーブルのルックアップ:
関数内の変数名と値の紐付けを管理するためのオーバーヘッドが発生します（PHP 8以降ではEX(opline)の最適化やJITにより大幅に軽減されていますが、それでもコストはゼロではありません）。
4. リターンアドレスの保存:
処理が終わった後にどこに戻るべきかというコンテキストをスタックに積みます。
この一連の処理は、C言語などの静的言語における関数呼び出しに比べると、動的言語であるPHP（Zend Engine）の動的な型解決や可変長引数の処理が絡むため、どうしても一定のCPUサイクルを消費します。
—
2. 内部関数（C言語製）の圧倒的な速さと「代償」
一方で、`strlen()` や `json_encode()` のようなPHPの内部関数は、PHPのソースコードツリーの中ではC言語（Zend Engineの拡張モジュール）として直接実装されています。
Zend VMからこれらを呼び出す際、オペコードは `ZEND_DO_ICALL`（Internal Call）という専用のハンドラを叩きます。
ユーザー定義関数のような「PHPバイトコードの解釈ループ」を挟まないため、関数自体の実行速度は極めて高速です。C言語の関数ポインタを直接ジャンプして実行しているようなものだからです。
「じゃあ、全部内部関数（C拡張）にすれば最速なの？」という疑問
ここで「なるほど、じゃあ処理の重い部分は全部C言語でPECL拡張（C拡張）として書けばいいんだ！」と思われた方、非常に鋭い視点です。実際にLaravelのコアや一部の超高速ライブラリ（SwooleやRoadRunnerのコンポーネントなど）はこのアプローチを取ります。
しかし、WebアプリケーションのビジネスロジックをすべてCで書くのは、開発効率（DX）や保守性の観点から現実的ではありませんよね。ここで登場するのが、近代PHPの切り札である OPcacheとJIT（Just-In-Time Compiler） です。
—
3. JITコンパイラによる「ユーザー定義関数のインライン化」の魔法
PHP 8で導入されたJIT（DynASMをベースにしたネイティブコード生成器）は、Zend VMの歴史を大きく変えました。
JITが有効な環境下では、頻繁に実行されるホットスポット（Hot spot）のオペコードを、Zend VMのバイトコード解釈をバイパスして、CPUが直接実行できるネイティブの機械語（Machine Code）へとコンパイルします。
ここで起きるのが、今回のメインテーマである「インライン化（Inlining）」の可能性です。
インライン化とは何か？
例えば、以下のような非常にシンプルなユーザー定義関数があるとします。
「わざわざ関数呼び出しのスタックフレームを作る必要なくない？ `add_tax` の中身を、呼び出し元のコードに直接埋め込んじゃおう（インライン展開）」
結果として、マシン語レベルでは以下のような状態に変換されます。
[スタックフレームの構築コスト ＝ ゼロ]
直接CPUレジスタ上で 1500 1.10 を計算する
このように、JITはユーザー定義関数であっても、そのオーバーヘッドを極限まで削ぎ落とし、内部関数や手書きのインラインコードに匹敵するパフォーマンスへと押し上げてくれるのです。
—
4. アーキテクトが現場で意識すべき「コードの書き方」
ここまで、Zend VMの内部挙動とJITの最適化について見てきました。「JITがあるなら、どんな書き方をしてもPHPが勝手によしなに最適化してくれるんだな」と思われるかもしれませんが、それは半分正解で半分不正解です。
Zend VMとOPcache/JITに愛される（＝最適化しやすい）コードを書くための、実用的な指針をいくつかシェアします。
① 小さすぎる関数の過剰な細分化（マイクロ・オーバヘッド）に注意する
JITが有効であればインライン化の恩恵を受けられますが、常にすべての関数がインライン化されるわけではありません。極端に小さな関数がループ内で何百万回も呼ばれるような構造（JITが無効な環境や、型が動的に揺らぐ環境）では、スタックフレームの構築コストがボトルネックになります。
// 悪い例（型が安定せず、関数呼び出しのオーバーヘッドが蓄積しやすい）
function get_array_item($arr, $key) {
return $arr[$key] ?? null;
}
for ($i = 0; $i < 1000000; $i++) { $val = get_array_item($data, $i); } // 良い例（配列アクセスのプリミティブなオペコードに留めるか、スコープをまとめる） for ($i = 0; $i < 1000000; $i++) { $val = $data[$i] ?? null; } ※PHP 8の型推論は非常に優秀ですが、配列のキーアクセスやオブジェクトのプロパティアクセスが動的に変化すると、Zend VMはポリモーフィックなキャッシュ（Guard）を挟むため、わずかに行数が膨らみます。
② 厳格な型宣言（`declare(strict_types=1);`）の重要性
Zend VMとJITが最も輝くのは、「型が完全に確定しているとき」です。
引数や戻り値に `int` や `float` などのスカラー型を厳格に指定し、`strict_types=1` を宣言することで、Zend VMは動的な型の揺らぎを考慮した「型チェックのフォールバック処理」を省略できます。
おわりに
PHPは、もはや「動的で遅いスクリプト言語」ではありません。Zend VMの洗練されたオペコード設計、強力なOPcache、そしてJITコンパイラの進化によって、非常にモダンで高速な実行エンジンへと昇華しています。
「なぜこの書き方が速いのか？」
「Zend VMはこのコードをどう解釈しているのか？」
こうした低レイヤの視点（解像度）を持つことで、皆さんが日々書くPHPコードの美しさと強靭さは一段と跳ね上がります。ぜひ、次のプロダクトのコードレビューや設計の際に、「Zend VMの気持ち」を少しだけ想像してみてください。
それでは、また次回の深淵なPHPの世界でお会いしましょう。