PHPのジェネレータ（Generators）によるメモリ効率化の物理的根拠
PHPの実行モデルを語る上で、配列（Array）というデータ構造の裏側にある「`HashTable`とZend Value（`zval`）の群れ」がどれほどのメモリフットプリントを消費するかを直視しなければならない。
数百万件のレコードを持つ巨大なデータセットを扱うとき、愚直に`range()`やDBからの全件フェッチを配列に格納すれば、Zend VMのヒープメモリは瞬く間に枯渇し、OOM（Out of Memory）キラーの餌食となる。
この限界を突破するための中核技術がジェネレータ（Generators）である。表面的には「`yield`キーワードを使ってメモリを節約する便利な構文」として片付けられがちだが、その実態は、Zend VMの実行コンテキスト（Execution Context）のヒープ退避と、コールスタックの物理的切断による「遅延評価（Lazy Evaluation）の極限形」に他ならない。
本稿では、Zend VMの内部構造、オペコード（Opcode）の挙動、そして関数フレームの生存期間に踏み込み、ジェネレータがなぜメモリを爆発させずに巨大なストリームを処理できるのか、その物理的根拠を解き明かす。
—
1. 従来の配列とメモリ消費の物理的背景
PHPの配列は、実態としてハッシュマップと双方向連結リストを兼ね備えた複合データ構造である`HashTable`として実装されている。
/ Zend/zend_types.h の概念的構造 /
typedef struct _bucket {
zval val;
zend_ulong h;
zend_string key;
} Bucket;
この`Bucket`構造体一つをとっても、`zval`（16バイト）に加え、ハッシュ値、キーのポインタ、衝突解決のためのポインタなどが絡み合い、オーバーヘッドを含めると1エントリあたり数十バイトから百数十バイトのメモリを消費する。
さらに、これらを一度のクエリや処理でメモリ上に全展開（Materialize）しようとすれば、CPUキャッシュのヒット率は劇的に低下し、PHP-FPMのプロセス空間における`memory_limit`の壁に激突する。
// 【アンチパターン】全件をメモリに展開する愚行
function getBigData_Bad(int $total): array {
$data = [];
for ($i = 0; $i < $total; $i++) {
$data[] = compute_heavy_payload($i); // 100万件あれば数100MB〜GB単位のzvalが生成される
}
return $data;
}
このコードが実行されると、Zend VMは全ての要素に対応する`zval`をヒープ上に構築し終えるまで処理を先に進めない。ここにメモリ効率化の余地はなく、ただリソースの暴力で殴り合っているに過ぎない。
---
2. ジェネレータの内部メカニズム：`Generator`オブジェクトとスタックフレームの退避
ジェネレータが関数内部で`yield`に到達した瞬間、PHPエンジン内部では何が起きているのか。
コールスタックからヒープへのコンテキスト移管
通常の関数呼び出しでは、関数が実行されるとZend VMのコールスタック（`zend_execute_data`）にスタックフレームがプッシュされ、関数が終了（`RETURN`）するとそのフレームは破棄される。
しかし、ジェネレータ関数は異なる。Zend VMが`ZEND_YIELD`オペコードに遭遇すると、以下の物理的処理が実行される。
1. スタックフレームの退避: 現在の関数の実行状態（ローカル変数、シンボルテーブル、命令ポインタ `opline`）を保持したまま、コールスタックからヒープ領域へ退避させる。
2. `Generator`インスタンスの生成: 内部的に`zend_generator`構造体がインスタンス化され、呼び出し元へ返却される。
3. 制御の返還: 呼び出し元（クライアントコード）に制御が戻り、ジェネレータ関数側は「一時停止（Suspended）」状態に入る。
/ Zend/zend_generators.h の概念 /
typedef struct _zend_generator {
zend_object std;
zend_execute_data execute_data; // 退避された実行コンテキスト
zend_op send_target;
zval value;
zval key;
// … 状態管理フラグ
} zend_generator;
クライアント側が`->next()`を呼ぶか、`foreach`ループで次のイテレーションを要求すると、Zend VMはヒープ上の`zend_execute_data`を再活性化し、直前の`yield`の次行から実行を再開する。
この仕組みにより、「データ全体を事前に生成して配列に詰める」必要性が完全に消滅し、「次に要求された瞬間に1つだけ値を算出する」逐次処理（Stream Processing）が成立するのである。
—
3. 実装検証：メモリ使用量の劇的な乖離
百聞は一見にしかず。100万件のデータを扱う際のメモリ消費量を、配列返却とジェネレータで比較する。
declare(strict_types=1);
// メモリ使用量を人間が読みやすい形式でフォーマットするヘルパー
function report_memory_usage(string $label): void {
$mem = memory_get_usage(true);
$peak = memory_get_peak_usage(true);
echo sprintf(“[%s] Current: %s MB | Peak: %s MB\n”,
$label,
number_format($mem / 1024 / 1024, 2),
number_format($peak / 1024 / 1024, 2)
);
}
// 1. 配列を返すアプローチ
function generate_array(int $limit): array {
$result = [];
for ($i = 0; $i < $limit; $i++) {
// 重いペイロードを模した配列を生成
$result[] = ['id' => $i, ‘payload’ => str_repeat(‘A’, 1024)];
}
return $result;
}
// 2. ジェネレータを返すアプローチ
function generate_generator(int $limit): Generator {
for ($i = 0; $i < $limit; $i++) {
// 必要な瞬間に1要素分だけ生成
yield $i => [‘id’ => $i, ‘payload’ => str_repeat(‘A’, 1024)];
}
}
$limit = 100_000; // 10万件
// — 実験 A: 配列 —
report_memory_usage(“Before Array”);
// $arr = generate_array($limit); // 100万件だと即死するので10万件に縮小
// report_memory_usage(“After Array”);
// unset($arr);
// — 実験 B: ジェネレータ —
report_memory_usage(“Before Generator”);
$gen = generate_generator($limit);
report_memory_usage(“After Generator Initiated (Data not evaluated yet)”);
$count = 0;
foreach ($gen as $key => $value) {
// 逐次処理を行うため、メモリ上に全件が同時に存在しない
$count++;
}
report_memory_usage(“After Generator Fully Iterated”);
実行結果のアーキテクチャ的解釈
配列アプローチでは、関数を呼び出した瞬間に数万・数百万の`zval`がヒープを圧迫し、ピークメモリが跳ね上がる。
一方、ジェネレータアプローチでは、`generate_generator()`を呼んだ直後（イテレーション前）のメモリ増加量はわずか数キロバイトの`Generator`オブジェクト本体の生成分のみである。`foreach`ループ内でも、1回のループサイクルが終われば古い`zval`は速やかにガベージコレクションやスコープ解放の対象となり、メモリフットプリントは常に一定（O(1)空間計算量）に保たれる。
—
4. OPcacheプリローディングとジェネレータの親和性
Zend VMの最適化において避けて通れないのがOPcacheとPreloading（PHP 7.4以降）の存在である。
Preloadingは、サーバー起動時（`php-fpm.conf`の`opcache.preload`ディレクティブで指定されたスクリプト）に、指定したクラスや関数を永続的な共享メモリ（SHM）にロードし、全リクエスト間で共有する仕組みだ。
ここで重要なのは、「ジェネレータ関数自体はOPcacheによってプリロード可能だが、生成されるデータや`Generator`インスタンスそのものはリクエストごとの動的状態（Runtime State）であるため共有できない」という点だ。
// Preload対象として極めて有効な、ジェネレータを活用したデータ処理パイプラインクラス
class LogStreamProcessor {
public function streamLargeLog(string $filePath): Generator {
$handle = fopen($filePath, ‘r’);
if ($handle === false) {
throw new RuntimeException(“Failed to open file.”);
}
try {
while (($line = fgets($handle)) !== false) {
// 行単位で遅延評価を行い、メモリ消費を抑える
yield json_decode($line, true, 512, JSON_THROW_ON_ERROR);
}
} finally {
fclose($handle); // スコープを抜ける、あるいはイテレーションが途中で中断された場合でも確実にリソースを解放
}
}
}
このクラスをOPcacheプリロードに含めることで、クラス定義やオペコードのコンパイルコスト（JITやバイトコードキャッシュの恩恵）を完全にゼロにしつつ、リクエスト時には巨大なログファイルを一滴ずつ安全に処理する、極めてクリーンで堅牢なアーキテクチャが完成する。
—
5. 限界の先へ：Fiber（ファイバー）との比較思想
PHP 8.1で導入されたFiber（ファイバー）は、ジェネレータの概念をさらに昇華させた「ローレベルな協調的マルチタスキング（Cooperative Multitasking）」のプリミティブである。
- ジェネレータ: データの生成・ストリーミングに特化。呼び出し元への値の返却と、内部ステートの保持を行う。
- ファイバー: 実行の中断と再開（Suspend/Resume）に特化。コールスタック全体を任意の深度で中断し、非同期I/Oやイベントループと統合できる。
ジェネレータの内部構造（`zend_execute_data`のヒープ退避）は、実はFiberのアーキテクチャの基礎プロトタイプでもある。ジェネレータを極めたエンジニアにとって、Fiberによる非同期プログラミングの遷移は自然な拡張領域となるだろう。
—
結びにかえて
ジェネレータの本質は、単なる「コードの小手先の書き換え」ではない。それは、Zend VMの実行コンテキストをプログラマの意志でコントロールし、メモリという有限な物理資源を極限まで効率的にマネジメントするための低レイヤの武器である。
フレームワークが提供する抽象化の層の裏側で、Zend VMがどのようにメモリを割り当て、どのようにオペコードを流しているか。その物理的根拠を把握したエンジニアだけが、億単位のトラフィックや数ギガバイトのデータストリームを涼しい顔して捌き切る、真にスケーラブルなWebシステムを設計できる。