Eonevolve Learning
Unity and DevelopmentUnity and codeAdvanced~6 min

Reading a Profiler Without Guessing

Snapshot

~75 sec

The Profiler splits a frame's cost into modules - CPU, rendering, memory - and a spike in one module points at a completely different fix than a spike in another. Guessing which system is slow before opening the Profiler usually wastes an optimization pass on the wrong target.

You will learn

  • Name the difference between a CPU-bound frame and a rendering-bound frame.
  • Read a spike in the CPU module down to the specific function causing it.
  • Avoid optimizing a system the Profiler never flagged as expensive.

Target outcome

You can look at a frame spike and say which Profiler module to open first.

Visual walkthrough

Visual walkthrough

~6 min

  1. Three modules, three different stories

    • CPU module

      Time spent in scripts, physics, and animation on the main thread.

    • Rendering module

      Time spent drawing - draw calls, batching, GPU-bound work.

    • Memory module

      Allocations and garbage collection - a hidden cause of CPU spikes.

  2. From a spike to the right fix

    The same symptom (a dropped frame) has a different root cause depending on which module actually spiked.

    Frame time spikes

    The game visibly stutters for one or more frames.

    1. check CPU first

      CPU module spikes

      A specific script or physics call dominates the frame.

    2. check GC alloc

      GC alloc spikes in CPU module

      A garbage collection pass interrupts the frame.

    Rendering module spikes

    Draw calls or GPU time dominate instead.

    The same symptom (a dropped frame) has a different root cause depending on which module actually spiked.

    Reading order

    1. Frame time spikes

      The game visibly stutters for one or more frames.

    2. CPU module spikes

      A specific script or physics call dominates the frame.

    3. GC alloc spikes in CPU module

      A garbage collection pass interrupts the frame.

    4. Rendering module spikes

      Draw calls or GPU time dominate instead.

    Connection explanations

    1. Frame time spikes → CPU module spikes (check CPU first)

      If one function's self time dominates the CPU module, that function is the fix target - not a general "optimize everything" pass.

    2. Frame time spikes → GC alloc spikes in CPU module (check GC alloc)

      A GC alloc spike usually means something is allocating every frame (a new list, a boxed value) rather than a slow algorithm.

    3. Frame time spikes → Rendering module spikes (check rendering)

      A rendering-module spike points at draw call count or shader cost, which a CPU-side script optimization will not fix.

  5. Diagnose the spike

    Frame time spikes every few seconds. The CPU module shows a recurring GC.Collect entry, and no single script function stands out. What should you look for next?

    Expected reasoning

    A source of repeated per-frame allocation - a new List or string built inside Update, LINQ calls in a hot path, or boxing a struct. The recurring GC.Collect points at garbage collection pressure, not a slow algorithm, so the fix is reducing allocations rather than optimizing a specific function's logic.

Go deeper