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

2026.08.25

ジェネレータとFiberのメモリ効率比較：遅延評価の真実とZend VMの内部構造

PHPによる大規模データ処理や非同期・並行処理の設計において、メモリ効率の限界を見極められていますか？
「何百万件ものレコードをDBからストリーミング処理する」「数千のタスクを並行制御する」。こうした高負荷なWebアプリケーションやAPIを構築する際、私たちは常にメモリ制限（`memory_limit`）との戦いを強いられます。

ネット上の浅薄な解説では、「ジェネレータはメモリ節約になる」「Fiberは非同期処理に便利」といった表面的なメリットしか語られません。しかし、テクニカルリードであるあなたなら、その裏側でPHPの実行エンジン（Zend VM）とOSのメモリ空間がどう振る舞っているかに関心があるはずです。

本稿では、ジェネレータ（Generator）とFiberのメモリ使用効率を、遅延評価（Lazy Evaluation）の観点から低レイヤのメモリ配置（HashTableやコールスタック）まで踏み込んで徹底比較します。実務で即座に使える堅牢な設計ルールとコード例を交えて、その本質を解き明かします。

—

1. 内部構造の解剖：なぜ「遅延評価」が必要なのか

WebリクエストがPHP-FPMに到達し、Zend VMがスクリプトを実行し始める瞬間、すべての変数はメモリ上に割り当てられます。しかし、全てのデータを一度にメモリへ展開する（Eager Evaluation）アプローチは、ビッグデータやストリーム処理の文脈において致命的な設計アンチパターンです。

データの全展開（Eager）が引き起こす悲劇

例えば、100万件のログ行を配列（`array`）で保持する場合を考えます。PHPの配列の実体は、順序付きハッシュテーブル（`Bucket`構造体の連続）です。ポインタのオーバーヘッド、ハッシュ値の保持、メモリの動的確保（malloc）の断片化により、数MBのテキストデータがPHPの内部メモリ空間では数十MB〜数百MBに膨れ上がります。

遅延評価（Lazy Evaluation）の仕組み

これを解決するのが遅延評価です。必要になったその瞬間（`yield`または再開時）にのみ次のデータを評価・生成することで、メモリ上のフットプリントを常にO(1)（定数オーダー）に抑え込みます。

—

2. ジェネレータとFiberのメモリ配置とコストの比較

ジェネレータとFiberは、どちらも「実行を中断・再開できる」という共通点を持っていますが、Zend VMにおける内部表現とメモリフットプリントは根本的に異なります。

ジェネレータ（Generator）のメモリ効率

  • 実体: `Generator`オブジェクトと、それに紐づく`zend_execute_data`およびスタックフレーム。
  • メモリ消費: 極めて低い（O(1)）。
  • 挙動: 関数が`yield`に到達すると、Zend VMはその時点の実行コンテキスト（ローカル変数やオペコードのポインタ）を一時退避し、呼び出し元に制御を戻します。メモリ上に保持されるのは「次の要素を生成するために必要な最小限の状態」のみであり、過去に生成したデータの履歴は保持されません。

Fiber（ファイバー）のメモリ効率

  • 実体: `Fiber`クラスのインスタンスと、完全に独立したコールスタック（Cレベルのスタック領域を含む）。
  • メモリ消費: 中〜高（O(N) または スタックサイズ依存）。
  • 挙動: Fiberは「協調的マルチタスキング（Cooperative Multitasking）」を実現するため、独自のコールスタックを持ちます。つまり、関数呼び出しのネストが深ければ深いほど、Fiberのコンテキストスイッチングとメモリ保持のコストは増大します。

> ⚠️ テクニカルリードの視点:
> 「非同期だから」という理由で、単純なイテレーション（データの順次処理）にFiberを採用するのはメモリの無駄遣いです。数千件のレコード処理でFiberを使うと、各Fiberが持つ独立したスタック領域がヒープを圧迫し、OOM（Out Of Memory）を引き起こすリスクが跳ね上がります。データストリーミングにはジェネレータを、処理のフロー制御や非同期I/Oの多重化にはFiberを使い分けるべきです。

—

3. 実務で証明する：メモリ消費量の実測比較とコード例

百聞は一見にしかず。メモリ消費量の違いを、厳密な型定義とメモリ計測を組み込んだ実用的なコードで検証します。

以下のコードは、大量データを扱うバッチ処理やAPIのエンドポイントを想定した、メモリ安全なジェネレータの設計例です。

  • 巨大なデータセットをメモリ効率良く遅延評価するためのジェネレータ
  • @param int $totalCount 生成する総レコード数
  • @return \Generator

    • /
    function streamLargeDataset(int $totalCount): \Generator
    {
    // メモリ上に配列を一切展開せず、1行ずつオンデマンドで生成する
    for ($i = 1; $i <= $totalCount; $i++) { // 実際の業務ではここでDBのカーソルやファイルポインタからフェッチする yield $i => [
    ‘id’ => $i,
    ‘payload’ => ‘Data payload string for record #’ . $i,
    ‘created_at’ => date(‘Y-m-d H:i:s’),
    ];

    // Zend VMのGC（ガベージコレクション）を助けるため、不要な一時変数を残さない
    }
    }

    // — 実行とメモリ計測 —

    // 実行前のメモリ使用量を記録
    $initialMemory = memory_get_usage(true);

    $generator = streamLargeDataset(1000000); // 100万件を想定

    $processedCount = 0;
    foreach ($generator as $id => $row) {
    // 10万件ごとにメモリ使用量を監視
    if ($id % 100000 === 0) {
    $currentMemory = memory_get_usage(true);
    $diff = ($currentMemory – $initialMemory) / 1024 / 1024;

    // ログ出力（本番ではPSR-3ロガーを使用すること）
    printf(
    “Processed: %d records | Memory Usage: %.2f MB (Diff: +%.2f MB)\n”,
    $id,
    $currentMemory / 1024 / 1024,
    $diff
    );
    }

    // ここでビジネスロジックや外部APIへの送信を行う
    // 処理が終わったデータは自動的にスコープ外となり、メモリから解放される
    }

    /

    • 【期待される出力結果の例】
    • Processed: 100000 records | Memory Usage: 14.00 MB (Diff: +0.00 MB)
    • Processed: 200000 records | Memory Usage: 14.00 MB (Diff: +0.00 MB)
    • …
    • Processed: 1000000 records | Memory Usage: 14.00 MB (Diff: +0.00 MB)
    • ※ 100万件を処理してもメモリ消費量がほぼ増加しない（O(1)の証明）

    /

    なぜこの設計が堅牢なのか？

    1. ストリーミングの徹底: 配列を返さず `yield` を用いることで、Zend VMのハッシュテーブルアロケーションを回避しています。
    2. スコープの局所化: ループ内で生成される配列は、次のループに移行した瞬間に参照カウントがゼロになり、次のガベージコレクションやアロケーターの再利用プールに戻されます。

    —

    4. アーキテクチャ設計ルール：ジェネレータとFiberの使い分け

    コードレビューで後輩エンジニアから「全てをFiberで非同期化したい」と言われたら、あなたはテクニカルリードとしてどう返すべきでしょうか？ 正解は以下の設計マトリクスに基づいた厳格なガイドラインの提示です。

    1. データの遅延イテレーションには「ジェネレータ」を強制する

    • 適用領域: DBからのフェッチ、CSV/JSONLファイルの行単位パース、外部APIからのページネーション取得。
    • 理由: メモリフットプリントが最小限であり、PHPの既存のイテレータ構文（`foreach`）と完全に統合されます。

    2. I/Oバウンドな多重タスク実行には「Fiber」を採用する

    • 適用領域: 複数のアプリアイランドに対する並行HTTPリクエスト（AmpやReactPHPなどのエコシステム、またはネイティブFiberベースの軽量ルーパー）、非同期イベントループ。
    • 理由: コールスタックを切り替えることで、ブロッキングI/Oを非同期に見せかけることが可能です。ただし、スタックメモリの消費量を常に見積もる必要があります。

    —

    5. 結び：限界を知る者だけが書けるコード

    PHPはもはや「おもちゃのスクリプト言語」ではありません。JITコンパイラの導入やZend VMの最適化により、正しく設計されたPHPアプリケーションは極めて高いスループットと省メモリ性を発揮します。

    しかし、エンジンの挙動を無視した安易なコードは、高負荷時に容赦なくシステムをクラッシュさせます。「なぜジェネレータはメモリを食わないのか」「Fiberのコールスタックの裏側で何が起きているのか」。この低レイヤの視点を持つことこそが、プロダクション環境の信頼性を担保する唯一の盾なのです。

    あなたの次のコードレビューでは、メモリの波及効果まで見据えた美しいアーキテクチャが採用されることを期待しています。

    スポンサーリンク
    " "
    タイトルとURLをコピーしました