♻️ Lesson 12.2: Object Pooling & Optimization

Why Instantiate/Destroy Hurts

Calling Instantiate is not free. Unity has to allocate managed and native memory, clone the prefab's component data, register the new object with every relevant system (physics, rendering, hierarchy), and wake up its scripts. Destroy is the mirror image: the object is torn down and its managed memory becomes garbage waiting for the collector.

Do that once and nobody notices. Do it for every bullet in a machine-gun, every spark in an explosion, every floating damage number, and two things go wrong:

• CPU cost per spawn. The allocation and setup work adds up on the main thread — a burst of spawns can be the exact spike you saw in the Profiler.
• GC pressure. All those destroyed objects pile up as garbage. Eventually the garbage collector runs, pauses the game for a few milliseconds, and the player feels a hitch — usually at the worst moment, mid-firefight.

💡 The mindset shift. Objects in a pool are never really "created" or "destroyed" during gameplay — they're switched on and off. A dead enemy isn't deleted; it's parked, reset, and waiting to be the next enemy.

The Pool Idea

A pool has just two operations. Get hands you a ready-to-use object: if a spare is available it reactivates that one, otherwise it creates a fresh one to grow the pool. Release takes a finished object, deactivates it, and files it back for next time. Here's the full lifecycle:

Figure 1: The pool get/release lifecycle. After the pool warms up, the "Instantiate" branch stops firing — every request is served by reactivating a parked object, so there's nothing to allocate or collect.

Notice the payoff: the first few requests may still instantiate, but once the pool holds enough objects for your peak demand, every future request just flips an object back on. That steady-state 0 B of GC allocation is exactly the flat line you were aiming for in the Profiler.

A Queue-Based Pool

The simplest pool is a Queue<T> of inactive objects. When you get, you dequeue one (or make a new one if the queue is empty) and activate it. When you release, you deactivate it and enqueue it. Here's a complete, generic pool you can drop into any project:

using System.Collections.Generic;
using UnityEngine;

public class SimplePool : MonoBehaviour
{
    [SerializeField] GameObject prefab;
    [SerializeField] int prewarm = 20;   // create this many up front

    readonly Queue<GameObject> pool = new Queue<GameObject>();

    void Awake()
    {
        // Warm the pool so the first burst of gameplay doesn't instantiate.
        for (int i = 0; i < prewarm; i++)
            pool.Enqueue(CreateOne());
    }

    GameObject CreateOne()
    {
        GameObject obj = Instantiate(prefab, transform);
        obj.SetActive(false);
        return obj;
    }

    // Borrow an object from the pool.
    public GameObject Get(Vector3 position, Quaternion rotation)
    {
        // Reuse a parked object, or grow the pool if none are free.
        GameObject obj = pool.Count > 0 ? pool.Dequeue() : CreateOne();

        obj.transform.SetPositionAndRotation(position, rotation);
        obj.SetActive(true);
        return obj;
    }

    // Return a finished object to the pool.
    public void Release(GameObject obj)
    {
        obj.SetActive(false);
        pool.Enqueue(obj);
    }
}

The object that borrows itself out is responsible for coming back. A bullet, for example, tells the pool to take it back after a lifetime or on impact — never calls Destroy:

using UnityEngine;

public class PooledBullet : MonoBehaviour
{
    public SimplePool Owner { get; set; }   // set by the pool/spawner
    [SerializeField] float lifeTime = 3f;

    float timer;

    void OnEnable() => timer = lifeTime;    // reset state every time we're reused

    void Update()
    {
        timer -= Time.deltaTime;
        if (timer <= 0f)
            Owner.Release(gameObject);      // return to the pool, do NOT Destroy
    }
}

Unity's ObjectPool<T>

You don't always have to write the plumbing yourself. Unity ships a battle-tested generic pool in UnityEngine.Pool called ObjectPool<T>. You give it callbacks for the four moments in an object's pooled life — create, get, release, and destroy — and it manages the collection, capacity, and even safety checks for you:

using UnityEngine;
using UnityEngine.Pool;

public class BulletSpawner : MonoBehaviour
{
    [SerializeField] PooledBullet bulletPrefab;

    ObjectPool<PooledBullet> pool;

    void Awake()
    {
        pool = new ObjectPool<PooledBullet>(
            createFunc:     CreateBullet,                       // make a new one
            actionOnGet:    b => b.gameObject.SetActive(true),  // borrowed
            actionOnRelease: b => b.gameObject.SetActive(false), // returned
            actionOnDestroy: b => Destroy(b.gameObject),        // pool trimmed
            collectionCheck: true,   // warns if you release the same object twice
            defaultCapacity: 20,
            maxSize: 200);           // above this, extras are destroyed not stored
    }

    PooledBullet CreateBullet()
    {
        PooledBullet b = Instantiate(bulletPrefab);
        b.SetPool(pool);             // so the bullet can release itself
        return b;
    }

    public PooledBullet Fire(Vector3 pos, Quaternion rot)
    {
        PooledBullet b = pool.Get();                 // borrow
        b.transform.SetPositionAndRotation(pos, rot);
        return b;
    }
}

The bullet releases itself through the pool reference it was handed:

using UnityEngine;
using UnityEngine.Pool;

public class PooledBullet : MonoBehaviour
{
    IObjectPool<PooledBullet> pool;
    [SerializeField] float lifeTime = 3f;
    float timer;

    public void SetPool(IObjectPool<PooledBullet> p) => pool = p;

    void OnEnable() => timer = lifeTime;

    void Update()
    {
        timer -= Time.deltaTime;
        if (timer <= 0f)
            pool.Release(this);      // hand myself back
    }
}

Cache GetComponent

Pooling solves spawn churn; the next wins are about what your scripts do every frame. The most common offender is calling GetComponent inside Update. It performs a lookup every single frame for a reference that never changes. Grab it once and store it:

// ❌ Slow: looks up the Rigidbody 60+ times a second, forever.
void Update()
{
    GetComponent<Rigidbody>().AddForce(Vector3.forward);
}

// ✅ Fast: look it up once, reuse the cached reference.
Rigidbody rb;

void Awake()
{
    rb = GetComponent<Rigidbody>();
}

void Update()
{
    rb.AddForce(Vector3.forward);
}

The same rule applies to Camera.main (a hidden FindGameObjectWithTag under the hood), GameObject.Find, and any other search. Do the lookup once in Awake or Start, cache the result, and reference the field thereafter.

Kill Per-Frame Allocations

Every allocation inside a per-frame method feeds the garbage collector you're trying to keep quiet. The Profiler's GC Alloc column names them; here's how to remove the usual suspects:

• String building. "Score: " + score allocates a new string each frame. Only update the text when the value actually changes, and prefer a StringBuilder or a preformatted approach for frequently changing HUD numbers.
• Temporary collections. new List<>() or new T[] inside Update allocates every frame. Create the collection once as a field and Clear() it for reuse.
• LINQ in hot loops. .Where(...).ToList() is readable but allocates iterators and lists. In per-frame code, write a plain for loop.
• Physics that returns arrays. Physics.RaycastAll and OverlapSphere allocate a new array each call — use the NonAlloc variants (RaycastNonAlloc, OverlapSphereNonAlloc) with a reused buffer.

// ✅ Reuse one buffer instead of allocating an array every frame.
readonly RaycastHit[] hits = new RaycastHit[16];

void Update()
{
    int count = Physics.RaycastNonAlloc(transform.position, transform.forward, hits, 50f);
    for (int i = 0; i < count; i++)
        Debug.Log(hits[i].collider.name);
}

Batching, Atlasing, LOD & Update Discipline

If profiling shows you're GPU-bound or drowning in draw calls, the wins move from code to content:

• Batching & atlasing. Objects that share a single material can be drawn together in one batch. Combine many small textures into one texture atlas (or a Sprite Atlas in 2D) so more objects share a material — the Frame Debugger from Lesson 12.1 shows exactly which draw calls this merges. Mark non-moving geometry as Static so Unity can batch it automatically.
• LOD (Level of Detail). A LOD Group component swaps a mesh for cheaper versions as it gets further from the camera — full detail up close, a simpler mesh in the distance, nothing at all beyond a threshold. It trades a little memory for far fewer triangles on screen, which matters most in large 3D scenes.
• Update discipline. Every Update has a small fixed cost, and hundreds of them add up. Don't run an Update that does nothing most frames. Options: disable components you don't need, run periodic logic on a coroutine or timer instead of every frame, and have one manager tick many objects rather than each object ticking itself.

// Instead of a per-frame check that only matters occasionally,
// run it a few times a second with a coroutine.
System.Collections.IEnumerator ScanForTargets()
{
    var wait = new WaitForSeconds(0.25f);   // 4x per second is plenty for AI sensing
    while (enabled)
    {
        DoExpensiveScan();
        yield return wait;                  // yields control; no per-frame cost
    }
}

Hands-on Challenge

Summary

🚀 What's Next?

You can now find bottlenecks and fix the most common ones. It's time to ship. In the module's mini-project, Lesson 12.3: Quality Settings, Builds & Shipping, you'll set up URP quality tiers and Player Settings, use Unity 6's new Build Profiles to produce a real build (including WebGL), trim its size, and run the full profile → optimize → build → test loop end to end. It's also the finale of the whole course.