🛠️ Lesson 2.5: Mini-Project — Profiling & Fixing a Stress Scene

The Plan & the Baseline

The golden rule from Lesson 2.1 governs everything here: measure, then fix, then measure again. We won't "optimize" anything until the Profiler points at it, and we won't declare a fix successful until the numbers move. The scene we build has exactly three problems, each drawn from a previous lesson:

1. Per-frame allocations — a manager whose Update builds strings and lists every frame (Lesson 2.3).
2. An expensive per-frame query — each agent calls FindObjectsByType<Agent>() every frame to find its neighbours (Lessons 2.1 & 2.3).
3. Hundreds of unbatched materials — every agent clones its material to tint it, exploding the SetPass count (Lesson 2.4).

Together these will drag a few hundred agents down to a stuttering ~25 FPS. Here's the target of the whole exercise: the Profiler CPU Timeline before (a tall, ugly frame) and after (a flat one under budget).

Step 1: Build the Stress Scene

Create a fresh URP scene. Add an empty ArenaSpawner GameObject and give it this script, which spawns a few hundred cube "agents." Each agent will (deliberately) misbehave in the next script.

using UnityEngine;

public class ArenaSpawner : MonoBehaviour
{
    [SerializeField] Agent _agentPrefab;   // a cube with the Agent script + a Renderer
    [SerializeField] int _count = 300;
    [SerializeField] float _area = 40f;

    void Start()
    {
        for (int i = 0; i < _count; i++)
        {
            Vector3 pos = new Vector3(
                Random.Range(-_area, _area), 0.5f, Random.Range(-_area, _area));
            Instantiate(_agentPrefab, pos, Quaternion.identity);
        }
    }
}

Now the deliberately-slow Agent. Every line of its Update commits one of our three sins: it re-scans the whole scene for neighbours, it allocates strings/lists, and it clones its material to tint itself. This is the "before."

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

public class Agent : MonoBehaviour
{
    Renderer _renderer;

    void Awake() { _renderer = GetComponent<Renderer>(); }

    void Update()
    {
        // ❌ PROBLEM 2: scan the ENTIRE scene every frame, for every agent.
        //    300 agents × FindObjectsByType = 300 full-scene scans per frame.
        Agent[] all = Object.FindObjectsByType<Agent>(FindObjectsSortMode.None);

        // ❌ PROBLEM 1: LINQ + ToList + a captured closure allocate every frame.
        Vector3 self = transform.position;
        List<Agent> neighbours = all
            .Where(a => a != this &&
                        Vector3.Distance(a.transform.position, self) < 6f)
            .ToList();

        // ❌ PROBLEM 1 (again): string built every frame for a debug label.
        string label = "Agent " + name + " sees " + neighbours.Count + " neighbours";
        gameObject.name = label;   // touching name each frame is itself wasteful

        // ❌ PROBLEM 3: '.material' CLONES the material → a unique instance per
        //    agent → the SRP Batcher can't keep them together → SetPass explodes.
        float t = Mathf.Clamp01(neighbours.Count / 8f);
        _renderer.material.color = Color.Lerp(Color.cyan, Color.red, t);
    }
}

Wire a cube prefab with the Agent script into the spawner, press Play, and you should see the frame rate crater. Resist the urge to fix anything yet — first we prove what's wrong.

Step 2: Profile & Read the Spike

Open Window → Analysis → Profiler, enter Play mode, and let it capture a few seconds. Then:

1. Click a representative frame in the CPU Usage module chart to freeze it. Note the total frame time (well over 16.7 ms).
2. In Timeline, find the fat blocks on the Main Thread — you'll see a large slab of script time.
3. Switch to Hierarchy and sort by Self ms. Agent.Update and, underneath it, FindObjectsByType should dominate.
4. Now sort by GC Alloc. Agent.Update shows a large per-frame allocation (the LINQ chain + strings).
5. Add the Rendering module and read the SetPass calls count — it'll be in the high hundreds because every agent has a cloned material.

You now have three pieces of evidence, each pointing at one problem. This is the whole discipline: the Profiler named the culprits, so every fix below is targeted, not a guess.

Step 3: Fix the Allocations

Tackle the garbage first (Lesson 2.3). Two allocation sources live in Update: the LINQ Where…ToList, and the per-frame string. We replace LINQ with a reused list and a plain loop, and we drop the pointless per-frame string entirely.

// Reused across frames instead of a fresh List every frame.
readonly List<Agent> _neighbours = new List<Agent>(32);

void UpdateNeighbours(Agent[] all)
{
    _neighbours.Clear();               // reuse the same backing array
    Vector3 self = transform.position;
    for (int i = 0; i < all.Length; i++)
    {
        Agent a = all[i];
        if (a == this) continue;
        // sqrMagnitude avoids the sqrt in Distance and the closure in Where.
        if ((a.transform.position - self).sqrMagnitude < 36f) // 6 * 6
            _neighbours.Add(a);
    }
    // No per-frame string. If you need a label, update it only on change,
    // or show it in a dedicated debug UI — not by rebuilding gameObject.name.
}

Re-profile just this change and the GC Alloc for Agent.Update drops toward 0 B (the scene query still allocates its array — that's the next fix). The LINQ/iterator/closure/string bytes are gone, and the incremental GC has far less to do.

Step 4: Fix the Scene Query

The worst CPU offender is FindObjectsByType running once per agent, per frame — 300 agents means 300 full-scene scans every frame, each also allocating an array. The fix is a registry: agents add themselves to one shared static list on enable and remove themselves on disable (Lessons 2.1 & 2.3). The whole scene is then known without any scanning.

using System.Collections.Generic;
using UnityEngine;

public class Agent : MonoBehaviour
{
    // ONE shared list of all live agents — no scanning, no allocation.
    public static readonly List<Agent> All = new List<Agent>(512);

    readonly List<Agent> _neighbours = new List<Agent>(32);
    Renderer _renderer;
    MaterialPropertyBlock _mpb;        // set up in Step 5

    void Awake()
    {
        _renderer = GetComponent<Renderer>();
        _mpb = new MaterialPropertyBlock();
    }

    // Register / unregister — mirror the += / -= discipline from Lesson 2.2.
    void OnEnable()  { All.Add(this); }
    void OnDisable() { All.Remove(this); }

    void Update()
    {
        _neighbours.Clear();
        Vector3 self = transform.position;
        // Iterate the shared registry — no FindObjectsByType, no allocation.
        for (int i = 0; i < All.Count; i++)
        {
            Agent a = All[i];
            if (a == this) continue;
            if ((a.transform.position - self).sqrMagnitude < 36f)
                _neighbours.Add(a);
        }

        ApplyTint(_neighbours.Count);  // Step 5
    }
}

Re-profile: Agent.Update's Self ms collapses because the 300 full-scene scans are gone, replaced by iterating one in-memory list. This is usually the single biggest win in the whole project — a classic "never search the scene every frame" fix.

Step 5: Fix the Unbatched Materials

The last problem is rendering (Lesson 2.4): _renderer.material.color = … reads the singular .material, which clones the material into a unique instance for every agent. 300 unique materials means the SRP Batcher can't keep them together and the SetPass count explodes. The fix is a MaterialPropertyBlock — per-object colour with no material cloning, so all agents keep sharing one material and one shader:

static readonly int BaseColorId = Shader.PropertyToID("_BaseColor");

void ApplyTint(int neighbourCount)
{
    float t = Mathf.Clamp01(neighbourCount / 8f);
    Color c = Color.Lerp(Color.cyan, Color.red, t);

    // Write colour into a property block — does NOT clone the material,
    // so every agent still shares one material/shader and batches together.
    _renderer.GetPropertyBlock(_mpb);
    _mpb.SetColor(BaseColorId, c);
    _renderer.SetPropertyBlock(_mpb);
}

Open the Frame Debugger (Lesson 2.4) before and after this change: beforehand it reports batches breaking on "different materials"; afterward the agents draw in far fewer batches. The SetPass calls count in the Rendering module drops from the high hundreds to a few dozen. If your agents all share one mesh too, you could go further with GPU Instancing — but the property-block fix alone restores SRP batching and is enough here.

🔎 One rule, remembered. Runtime per-object visual variation belongs in a MaterialPropertyBlock, never in renderer.material. That singular property is a material-cloning trap that silently multiplies your materials and wrecks batching — one of the most common rendering-performance bugs in real projects.

Step 6: Re-measure Before/After

Now prove it. Capture a fresh profile of the fixed scene and compare all four numbers against the baseline you wrote down in Step 2:

For a rigorous before/after, use the Profile Analyzer package (Lesson 2.1). Capture a range of frames before your fixes and save it; capture another range after; load both into the Analyzer's Compare view. It diffs every marker and shows exactly which ones got faster and by how much — turning "it feels better" into "Agent.Update median dropped from 0.11 ms to 0.004 ms." That is the deliverable a professional performance pass produces: not a vibe, a measured delta.

Extend It

Summary

Extend it: add the uniform-grid spatial partition to scale past 2,000 agents, convert rendering to true GPU Instancing, and — the natural next step — move the neighbour computation into a parallel Burst job. That last one is exactly where the course goes next.

🚀 What's Next?

You've mastered the diagnostic half of performance: measure, find, fix, prove. Module 2 got the most out of a single main thread. Module 3 changes the game — instead of making one thread do less, you make many threads share the work. In Lesson 3.1: Data-Oriented Thinking, we start the Job System & Burst track, and the O(n²) neighbour loop you just wrestled becomes the perfect candidate for safe, Burst-compiled parallelism.