【実務・中級編】PHPのジェネレータ（Generator）とFiberのメモリ効率比較：遅延評価とリソース消費の物理的差異 – PHPコア・内部エンジンと高速化・並行処理の極意解析バイブル

PHPを掌握する極限の知見：GeneratorとFiberのメモリ効率比較 —— 遅延評価とリソース消費の物理的差異

コードレビューの場で、同僚が平然と数百万件のレコードを配列に詰め込んだり、非同期処理の真似事として安易にFiberを持ち出したりするのを見るたびに、私は一人のアーキテクトとして深い絶望と、同時に強烈な使命感を覚える。

「なぜその実装にしたのか？」と問うと、返ってくるのは「動くからです」という薄っぺらい返答だ。
Webアプリケーションの1リクエストは、Zend Engineのメモリ空間における儚い生命の燃焼に他ならない。FPMワーカーが抱える有限のヒープ、OSが割り当てる仮想メモリの境界線を意識せずして、プロフェッショナルを名乗ることは許されない。

今回は、PHPのメモリ効率と制御フローの極限を語る上で避けて通れない2つの機能、Generator（遅延評価イテレータ）とFiber（協調的マルチタスク／スタックフルコルーチン）をテーマに選んだ。
これらがPHPの内部（Zend VM）でどのように構造体を形成し、メモリを浪費し、あるいは節約しているのか。その物理的差異を丸裸にしていこう。

—

1. Zend VMにおける「実行コンテキスト」の物理的実態

まず大前提として、PHPの関数やメソッドが実行されるとき、Zend VMは何を行っているかを理解しなければならない。

通常の関数呼び出しでは、Zend VM上に `zend_execute_data` という実行コンテキスト（スタックフレーム）が構築される。ここにはローカル変数、引数、現在実行中のオペコード（Opcodes）のポインタなどが保持される。通常、関数がリターンすればこのスタックフレームは即座に破棄され、メモリは解放される。

しかし、Generator と Fiber は、この「消えゆくはずの実行コンテキスト」を意図的にヒープ上に退避させ、生存期間を延長する仕組みだ。ここに両者の決定的な設計思想の違いがある。

—

2. Generator：極限まで削ぎ落とされた「単方向の遅延評価」

内部構造とメモリ効率

Generatorは、PHP 5.5で導入されて以来、大容量データ処理の救世主として君臨してきた。
Zend VMの視点から見ると、Generatorは `Generator` オブジェクトと、内部的に保持される `zend_execute_data` および `zend_generator` 構造体によって構成される。

配列がメモリ上に全データを連続した領域（`Bucket` 配列）として展開するのに対し、Generatorは「次に何をすべきかというクロージャ的状態」だけを保持する。

メモリ計算量: $O(1)$ （データの総数に依存せず、常に定数オーダーのメモリしか消費しない）
スタックの扱い: `zend_generator` は、再開可能な最小限の実行状態（ローカル変数とオペコードポインタ）だけをヒープ上の専用構造体に確保する。コールスタック全体を丸ごと保持するわけではない。

実務におけるGeneratorの美学

数百万件のデータベースレコードをストリーミング処理する際、全件をメモリにロードする愚を犯してはならない。Generatorを用いることで、Zend VMは「1行処理しては捨て、処理しては捨て」という極限の省メモリサイクルのループを回すことができる。

—

3. Fiber：強力だが「重い」、スタックフルコルーチンの代償

PHP 8.1で導入されたFiberは、非同期I/Oや並行処理のパラダイムを根本から変えた。しかし、その強力さゆえの「コスト」を正しく理解しているエンジニアは驚くほど少ない。

内部構造とメモリ効率

Fiberはスタックフルコルーチン（Stackful Coroutine）である。つまり、Generatorが「現在の関数のローカル状態」しか保持しないのに対し、Fiberは「呼び出し元からFiber内部に至るまでのコールスタック全体（`zend_fiber_context`）」を丸ごとヒープ上に構築する。

メモリ計算量: コールスタックの深さに比例したメモリ消費。初期化コストおよびメモリフットプリントはGeneratorの比ではない。
C言語レベルのスタック管理: Fiberは内部で独自のCスタック（通常は数キロバイトから状況に応じたサイズ）を割り当てる。そのため、コンテキストスイッチのオーバーヘッドがGeneratorよりも遥かに重い。

なぜ「安易なFiberの乱用」はバグの温床になるのか

Fiberは「どこからでも一時停止し、どこからでも再開できる」という強力な特性を持つ。しかし、これは裏を返せば、「コールスタックの生存期間が予期せぬ形で延びる」ことを意味する。
外部ライブラリが持っているグローバルな状態や、DBコネクションのトランザクションコンテキストがFiberを跨いで予期せぬ順序でインタリーブされた場合、デバッグが極めて困難な競合状態（Race Condition）やメモリリークを引き起こす。

—

4. 徹底比較：Generator vs Fiber

—

5. 実務で証明された設計パターン：堅牢なリファレンスコード

百聞は一見に如かず。ここでは、メモリを限界まで絞りつつ、安全にデータをストリーミング処理する Generatorを活用した実用的なETL（Extract/Transform/Load）パイプライン のコードを示す。

このコードは、数ギガバイトのCSVファイルを読み込み、メモリを枯渇させることなく安全に型変換とバリデーションを行いながらDBへバルクインサートする実務仕様の設計だ。

極限のメモリ効率を実現するデータストリーミングプロセッサ

@template TKey

@template TValue

/
class StreamPipeline
{
/

大容量ファイルを1行ずつメモリ上に展開せずに遅延読み込みするGenerator
@param string $filePath
@return Generator>

/
public static function extractCsv(string $filePath): Generator
{
$handle = @fopen($filePath, ‘rb’);
if ($handle === false) {
throw new RuntimeException(“指定されたファイルを開くことができません: {$filePath}”);
}

try {
// ヘッダー行の取得
$header = fgetcsv($handle);
if ($header === false) {
return;
}

$line = 1;
while (($row = fgetcsv($handle)) !== false) {
$line++;
// 空行のスキップ
if ($row === [null] || $row === false) {
continue;
}

// カラム数とヘッダー数の整合性チェック
if (count($header) !== count($row)) {
// 実務ではロガーに流すかスキップ処理とする
continue;
}

// 連想配列にマッピングしてyield（この瞬間のみメモリを使用し、即座に消費解放される）
yield $line => array_combine($header, $row);
}
} finally {
// 例外が発生した場合でも確実にリソース（ファイルハンドル）を解放する
// Zend VMのGC頼みにしないのがプロの流儀
fclose($handle);
}
}

データを加工するトランスフォーマー（遅延評価パイプライン）
@param Iterator> $iterator
@return Generator>

/
public static function transform(Iterator $iterator): Generator
{
foreach ($iterator as $key => $row) {
// ビジネスロジックに基づくバリデーションと型変換
if (!isset($row[‘id’], $row[‘email’])) {
continue;
}

yield $key => [
‘id’ => (int)$row[‘id’],
‘email’ => filter_var($row[‘email’], FILTER_VALIDATE_EMAIL) ?: null,
‘created_at’ => new \DateTimeImmutable($row[‘created_at’] ?? ‘now’),
];
}
}

チャンク単位でバルク処理を実行するローダー
@param Generator> $generator
@param int $chunkSize
@return Generator 処理した総件数を返す

/
public static function loadInChunks(Generator $generator, int $chunkSize = 500): Generator
{
$buffer = [];
$totalProcessed = 0;

foreach ($generator as $item) {
// バリデーションエラーなどでnullになったものは除外
if ($item[‘email’] === null) {
continue;
}

$buffer[] = $item;
$totalProcessed++;

if (count($buffer) >= $chunkSize) {
self::persistToDatabase($buffer);
$buffer = []; // バッファをクリアしてメモリを維持
}
}

// 剰余データのフラッシュ
if (!empty($buffer)) {
self::persistToDatabase($buffer);
}

yield $totalProcessed;
}

模擬的なDB永続化処理
@param array> $chunk

/
private static function persistToDatabase(array $chunk): void
{
// 実際のプロダクションコードではここでPDOのトランザクションとプレースホルダーを用いたバルクINSERTを実行する
// 例: INSERT INTO users (id, email, created_at) VALUES …

// デバッグ出力（メモリ使用量を抑えつつ安全に実行されている証左）
// echo “Flushed ” . count($chunk) . ” records. Peak Memory: ” . memory_get_usage(true) . “\n”;
}
}

// — 実行例のエントリーポイント —
/
$filePath = __DIR__ . ‘/huge_users.csv’;
$pipeline = StreamPipeline::loadInChunks(
StreamPipeline::transform(
StreamPipeline::extractCsv($filePath)
),
1000
);

foreach ($pipeline as $processedCount) {
echo “処理完了総数: {$processedCount} 件\n”;
}
/

このコードが美しい理由

1. リソースリークの完全排除: `try-finally` 構文によって、例外がスローされた場合でも必ず `fclose()` がコールされる。
2. $O(1)$ メモリフットプリント: 巨大なCSVが相手であっても、メモリ上に乗るのは常に `chunkSize` で指定された数（例: 1000件分）の配列のみである。
3. パイプラインの合成可能性: `Extract` -> `Transform` -> `Load` が完全に分離され、それぞれがイテレータを介して美しく結合されている。

—

6. アーキテクトからの最終提言：適材適所の境界線

PHPコードをレビューするとき、私は次の基準でこれらを見極める。

データを順次読み込んで流すだけなら、絶対に `Generator` を使え。 余計なスタックコンテキストの生成コストを払う必要はない。
イベント駆動型の非同期サーバーや、複数の非同期タスク間で複雑なコンテキストスイッチが必要な場合のみ、覚悟を持って `Fiber` を採用せよ。 ただし、フレームワーク層やライブラリ層の設計者が実装すべき領域であり、ビジネスロジックの平易なコードで安易に手を出すべきではない。

PHPはもはや「動くだけのスクリプト言語」ではない。Zend Engineの挙動とメモリの物理的制約を掌握した者だけが、高負荷に耐えうる真に堅牢なWebシステムを構築できるのだ。次回のコードレビューでは、メモリの足音を聞き逃さない洗練されたコードに出会えることを期待している。