♻️ Lesson 2.3: Writing Garbage-Free Code

The GC and Why Spikes Hurt

C# is garbage-collected: you new a reference type, use it, and the garbage collector reclaims it once nothing points at it. Convenient — but not free. Unity historically used a stop-the-world collector: when it ran, your entire game froze while it walked the heap. On a big heap that's a multi-millisecond pause, and a pause is a dropped frame.

Unity 6's default is the incremental GC, which splits that work across several frames so no single frame eats the whole collection. It's a genuine improvement — but it is not a licence to allocate freely. Incremental collection still costs CPU time every frame it's active, it can still spike when it must finish a collection under pressure, and the more garbage you produce the more often it runs. The winning move is unchanged: produce so little garbage that the GC almost never needs to run.

Here is the causal chain, from the small allocations you sprinkle through Update to the hitch the player feels:

Figure 1: How small, frequent allocations become a visible hitch. Each source feeds the managed heap; a fuller heap makes the collector run more often; a collection under pressure spikes a frame. Cut the sources at the top and the whole chain never fires.

Where Garbage Comes From

Most per-frame garbage is invisible until you learn to see it. These are the usual suspects — each looks harmless and each allocates every time it runs.

The through-line: allocation happens on new of a reference type, and on the hidden news the compiler inserts for boxing, closures, and iterators. Learn to spot the hidden ones and half the battle is won. The Profiler's GC Alloc column is your ground truth — if you're unsure whether a line allocates, put a marker around it and read the number.

Structs vs Classes

The cheapest allocation is the one that never touches the heap. A class is a reference type: new-ing one always allocates on the managed heap and creates GC work. A struct is a value type: a local struct lives on the stack (or inline inside its container), costs nothing to "allocate," and never bothers the GC.

So for small, short-lived, data-only bundles — a grid coordinate, a hit result, a damage packet — prefer a struct. This is exactly why Unity's own math types (Vector3, Quaternion, float3) are structs: they're created and discarded constantly, and if each were a class every vector math line would allocate.

// CLASS: every 'new GridCoord(...)' allocates on the heap → GC work.
public class GridCoordClass { public int X, Y; }

// STRUCT: a local lives on the stack, zero GC. Prefer this for small data.
public readonly struct GridCoord
{
    public readonly int X, Y;
    public GridCoord(int x, int y) { X = x; Y = y; }
}

Strings & StringBuilder

String building is the single most common source of per-frame garbage, because HUDs update text every frame. Since strings are immutable, concatenation allocates a new string for the result and each intermediate:

// ❌ Allocates several strings EVERY frame the HUD updates.
void Update()
{
    scoreLabel.text = "Score: " + score + " / " + target + " pts";
}

Two fixes, in order of preference:

1. Don't build the string at all unless it changed. The cheapest string work is the work you skip. Cache the last value and only rebuild when it differs.
2. When you must build one, reuse a StringBuilder — a mutable buffer you Clear() and refill instead of allocating fresh.

readonly System.Text.StringBuilder _sb = new System.Text.StringBuilder(32);
int _lastScore = -1;

void Update()
{
    if (score == _lastScore) return;   // only rebuild on change
    _lastScore = score;

    _sb.Clear();
    _sb.Append("Score: ").Append(score).Append(" / ")
       .Append(target).Append(" pts");
    scoreLabel.SetText(_sb);           // TMP takes a StringBuilder, no alloc
}

💡 TextMeshPro's SetText. Assigning to .text takes a string (which you had to allocate). TMP's SetText(StringBuilder) and its numeric overloads write straight from your buffer with no managed allocation — the idiomatic garbage-free way to update on-screen numbers.

NonAlloc Physics APIs

Physics queries are a sneaky allocator. The convenient forms return a freshly-allocated array every call — fine once, ruinous in FixedUpdate:

// ❌ Allocates a new Collider[] every physics step.
void FixedUpdate()
{
    Collider[] hits = Physics.OverlapSphere(transform.position, radius);
    foreach (var h in hits) Damage(h);
}

Unity provides NonAlloc variants that write into a buffer you own and reuse. You allocate the array once, and each query fills it and returns how many results it wrote:

readonly Collider[] _hitBuffer = new Collider[16];   // allocated ONCE

void FixedUpdate()
{
    int count = Physics.OverlapSphereNonAlloc(
        transform.position, radius, _hitBuffer);
    for (int i = 0; i < count; i++) Damage(_hitBuffer[i]);
}

The same pattern exists across the physics API — RaycastNonAlloc, SphereCastNonAlloc, OverlapBoxNonAlloc, and 2D equivalents. Size the buffer for your worst realistic case; results beyond its length are simply dropped (the return count tells you if you hit the cap). One reused array replaces an allocation on every physics tick.

Pooling & Caching Lookups

You met object pooling in Unity Intermediate — instead of Instantiate/Destroying bullets (which allocates and generates garbage), you keep a pool of inactive objects and recycle them. Unity 6 ships a built-in generic pool, ObjectPool<T> (namespace UnityEngine.Pool), so you no longer hand-roll one:

using UnityEngine.Pool;

public class BulletSpawner : MonoBehaviour
{
    [SerializeField] Bullet _prefab;
    ObjectPool<Bullet> _pool;

    void Awake()
    {
        _pool = new ObjectPool<Bullet>(
            createFunc:   () => Instantiate(_prefab),
            actionOnGet:  b => b.gameObject.SetActive(true),
            actionOnRelease: b => b.gameObject.SetActive(false),
            actionOnDestroy: b => Destroy(b.gameObject),
            defaultCapacity: 64, maxSize: 256);
    }

    public Bullet Fire()
    {
        var b = _pool.Get();        // reuses an inactive bullet — no Instantiate
        b.OnDone = () => _pool.Release(b);  // return it when finished
        return b;
    }
}

The pool turns a per-shot Instantiate (heap allocation + GC pressure + the cost of building a GameObject) into a cheap activate/deactivate of an object that already exists. UnityEngine.Pool also offers ListPool<T>, DictionaryPool<T>, and friends for pooling the temporary collections that would otherwise allocate in a method.

The other everyday allocation-and-cost sink is repeated component lookups. GetComponent — and far worse, FindObjectOfType/FindObjectsByType — are not free, and calling them every frame is pure waste when the answer never changes:

// ❌ Looks up the Rigidbody every single frame.
void Update() { GetComponent<Rigidbody>().AddForce(Vector3.up); }

// ✅ Look it up ONCE, cache the reference, reuse it forever.
Rigidbody _rb;
void Awake() { _rb = GetComponent<Rigidbody>(); }
void Update() { _rb.AddForce(Vector3.up); }

A Before/After Refactor

Let's put it together. Here's a plausible enemy-AI method that runs every frame and allocates on almost every line — a poster child for GC pressure. Read it and count the allocations:

using System.Linq;
using System.Collections.Generic;
using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    public float senseRadius = 8f;

    void Update()
    {
        // 1) Allocates a new Collider[] every frame.
        Collider[] near = Physics.OverlapSphere(transform.position, senseRadius);

        // 2) LINQ: Where + OrderBy + ToList — several allocations + a closure
        //    capturing 'transform.position'.
        List<Collider> players = near
            .Where(c => c.CompareTag("Player"))
            .OrderBy(c => Vector3.Distance(c.transform.position, transform.position))
            .ToList();

        if (players.Count > 0)
        {
            // 3) GetComponent every frame (no caching).
            var target = players[0].GetComponent<PlayerHealth>();

            // 4) String concatenation → new string(s) every frame.
            Debug.Log("Targeting " + target.name + " at range " + senseRadius);
        }
    }
}

Four allocation sources, all on the hot path: the physics array, the LINQ chain plus its closure, the uncached GetComponent, and the string concat feeding Debug.Log (which also boxes senseRadius). Now the garbage-free rewrite — same behaviour, 0 B/frame:

using UnityEngine;

public class EnemyAI : MonoBehaviour
{
    public float senseRadius = 8f;

    // Allocate ONCE. Reused every frame.
    readonly Collider[] _near = new Collider[32];

    void Update()
    {
        // 1) NonAlloc fills our reusable buffer — no array allocation.
        int count = Physics.OverlapSphereNonAlloc(
            transform.position, senseRadius, _near);

        // 2) Manual nearest-player scan — no LINQ, no closure, no ToList.
        Collider best = null;
        float bestSqr = float.MaxValue;
        Vector3 self = transform.position;
        for (int i = 0; i < count; i++)
        {
            var c = _near[i];
            if (!c.CompareTag("Player")) continue;
            // sqrMagnitude avoids the sqrt in Distance — cheaper, still orders correctly.
            float d = (c.transform.position - self).sqrMagnitude;
            if (d < bestSqr) { bestSqr = d; best = c; }
        }

        // 3) TryGetComponent: no allocation, and null-safe.
        if (best != null && best.TryGetComponent(out PlayerHealth target))
        {
            // 4) No per-frame logging on the hot path. If you must log,
            //    gate it or use a marker instead of building strings.
            target.MarkTargeted();
        }
    }
}

Line for line: the physics buffer is now a reused field; the LINQ chain became a plain for loop with a running best (and sqrMagnitude instead of Distance to skip a square root); TryGetComponent replaces the allocating GetComponent-then-null-check; and the per-frame string log is gone. Profile it and the GC Alloc for this method reads 0 B — and, because we cut the LINQ and the sqrt too, it's faster on the CPU as well. Garbage-free and cheaper: the two usually travel together.

🔎 Don't do this everywhere. This level of hand-tuning belongs on the hot path — code that runs every frame or thousands of times. In tools, setup, menus, and cold code, LINQ's clarity and a bit of garbage cost you nothing a player will ever feel. Optimize where the Profiler points, and leave readable code readable everywhere else.

Hands-on Challenge

Summary

🚀 What's Next?

We've squeezed the CPU and the managed heap. But even perfectly garbage-free C# can be throttled by the other side of the frame: how many times the CPU has to tell the GPU to draw something. In Lesson 2.4: Draw Calls & Batching, we move to rendering cost — what a draw call really is, and how the SRP Batcher, GPU Instancing, and Unity 6's GPU Resident Drawer collapse thousands of them.