オブジェクトプールとデータ指向設計

なぜ「毎フレーム生成・破棄」がゲームを止めるのか

60fpsのゲームは1フレームあたり約16.6ms、120fpsなら約8.3msというフレーム予算の中で、入力処理・ゲームロジック・物理・描画をすべて終えなければなりません。この予算を1回でも超えれば、その瞬間に表示は間に合わずカクつき（フレーム落ち）として観測されます。問題は、弾丸・パーティクル・エフェクトのように毎フレーム大量に生まれては消えるオブジェクトを素直に new / delete で扱うと、予算を食い潰す二つのコストが発生することです。

一つはアロケーションそのもののコストです。汎用ヒープ確保（メモリアロケータの内部動作 が扱う領域）は空き領域の探索・分割・メタデータ更新を伴い、生成破棄を繰り返すとヒープが断片化して確保がさらに遅くなります。もう一つがガベージコレクション（GC）です。C#（Unity）やJavaScript/TypeScriptなどマネージド言語では、捨てたオブジェクトはGCが後でまとめて回収します。この回収は往々にしてワールドを止める停止（stop-the-world）を伴い、あるフレームだけ突発的に数ミリ秒〜数十ミリ秒奪う——これがGCスパイクであり、フレーム落ちの典型的な原因です。

オブジェクトプール：確保を「使い回し」に置き換える

オブジェクトプールは、必要になるたびに確保するのをやめ、起動時やシーン開始時に上限個数ぶんまとめて確保しておき、以後はその中から「貸し出す／返す」だけで運用する手法です。生きているオブジェクトを実際に消すのではなく、非アクティブ状態にしてプールへ戻す。次に必要になったら戻ってきたものを再初期化して使う。これにより実行時のヒープ確保がゼロになり、マネージド環境ならGC対象の新規生成も止まります。

空き管理にはフリーリストを使うのが定石です。空きスロットの添字を積んだスタック（またはリンクリスト）を持ち、確保は先頭をpop、解放は末尾へpushするだけ。どちらも O(1) で、汎用ヒープのような探索も断片化も起きません。

// 固定長プール：確保・解放は O(1)、実行時アロケーションなし
public sealed class BulletPool {
    readonly Bullet[] items;   // 事前確保した実体
    readonly int[] freeStack;  // 空きスロットの添字を積むスタック
    int top;                   // フリーリストの先頭

    public BulletPool(int capacity) {
        items = new Bullet[capacity];
        freeStack = new int[capacity];
        for (int i = 0; i < capacity; i++) {
            items[i] = new Bullet();
            freeStack[i] = i;   // 最初は全スロットが空き
        }
        top = capacity;
    }

    public int Rent() {              // 貸し出し
        if (top == 0) return -1;     // 枯渇：拡張するか要求を捨てる
        return freeStack[--top];     // pop
    }

    public void Return(int id) {     // 返却
        items[id].Reset();           // 状態を初期化して再利用可能に
        freeStack[top++] = id;       // push
    }
}

データ指向設計：AoSからSoAへ

横にスクロール

アロケーションを消しても、データの並べ方が悪ければキャッシュミスで遅いままです。ここで効くのがデータ指向設計（Data-Oriented Design、DOD）です。オブジェクト指向が自然に導く配置はAoS（Array of Structures、構造体の配列）——1体ぶんのフィールドをまとめた構造体を並べます。対してSoA（Structure of Arrays、配列の構造体）は、同じフィールドを別々の連続配列に集めます。

AoS（構造体の配列）: 1体ぶんが連続。使わない成分も同じ行に混ざる
  [x0 y0 z0 hp0 tag0][x1 y1 z1 hp1 tag1][x2 y2 z2 hp2 tag2]...

SoA（配列の構造体）: 成分ごとに連続。位置更新は x,y,z 配列だけ触る
  x:  [x0 x1 x2 x3 ...]
  y:  [y0 y1 y2 y3 ...]
  z:  [z0 z1 z2 z3 ...]
  hp: [hp0 hp1 hp2 ...]   ← 位置更新ループでは読み込まれない

CPUはメモリを1バイト単位ではなくキャッシュライン（多くのアーキテクチャで64バイト）単位でロードします。位置を全体更新するループを考えると、AoSでは1体読むたびに hp や tag など使わない成分まで同じラインに載って運ばれ、キャッシュラインの実効利用率が下がります。SoAなら x, y, z の配列だけを頭から舐めるので、ロードしたラインの全バイトが有効データになり、キャッシュミス率が下がる。さらに連続した同型データはハードウェアプリフェッチャが先読みしやすく、SIMD/SIMTによる並列化 にも素直に載ります。同じ計算式でも、配置を変えるだけで数倍の差が出るのはこのためです。

SoAが常に勝つわけではありません。「1体の全フィールドをまとめて読む」アクセスパターンではAoSが有利で、実務ではホットな更新ループで触る成分だけをSoA化し、残りはまとめて持つ折衷（AoSoA、ブロック化SoA）も使われます。判断軸は「そのループが実際にどのフィールドを、どの順で触るか」です。

GCスパイク回避とフレーム予算の管理

プールとSoAは、実時間ゲームの二大要求——ゴミを出さないこととキャッシュに載せること——に同時に効きます。マネージド言語では特に、更新ループ内の何気ない記述がゴミを生みます。ボックス化（値型をobjectに入れる暗黙変換）、クロージャやイテレータの内部生成、params配列、文字列連結、List の再確保などは、毎フレーム回れば確実にGC圧を上げます。ホットパスでは確保ゼロ（zero-allocation）を原則に、事前確保したバッファとプールだけで回すのが鉄則です。

フレーム予算の管理は「平均を速くする」だけでは足りず、最悪フレームを予算内に収める発想が要ります。重い処理を1フレームに集中させず複数フレームへ分割する（time-slicing）、生成のバースト（爆発で弾が一斉に出る等）をプールの事前確保で吸収する、GCが動くタイミングをローディング画面など見えない箇所へ誘導する（世代別GCの世代境界やインクリメンタルGCの活用）、といった手を組み合わせます。

まとめ

実時間ゲームの最適化は、フレーム予算という厳格な締め切りを毎フレーム守り続ける戦いです。毎フレームの生成破棄はヒープ確保コストとGCスパイクという二重の負担を生み、フレーム落ちを招きます。オブジェクトプールは確保を事前確保配列の使い回しに置き換え、フリーリストによる O(1) の貸出返却で実行時アロケーションとGC対象の生成をなくします。データ指向設計はAoSをSoAへ組み替え、走査で触る成分だけをキャッシュラインに連続して載せることでミス率を下げ、SIMDにも道を開きます。仕上げは計測で、平均ではなく1%tile・0.1%tileのスパイクを指標に、確保バイト数をゼロへ、キャッシュミスを最小へと追い込む。プールでゴミを出さず、SoAで局所性を上げ、処理を予算内に収める——この三点が、カクつかないゲームを支えるデータ指向の実装原則です。