Turn ‘slow’ into an observation
Profiler shows where an app spends time each frame. Optimisation is not a sequence of random code tweaks; it is a loop of reproducing a scene, observing a bottleneck, and testing one hypothesis.
Do not draw final conclusions from Editor numbers alone. Recheck a comparable target device whenever possible.
An order for the first 30 minutes
Do not try to read every module at once. Start with the largest part of the frame budget. Treat per-frame allocation samples in CPU Usage and longer memory trends in the Memory module as different signals.
- Make the problematic scene and action repeatable.
- Select the problematic frame in CPU Usage and expand the largest entry under PlayerLoop.
- Inspect the GC.Alloc column in Hierarchy and the magenta GC.Alloc samples in Timeline.
- Enable Allocation Call Stacks and repeat the action to locate the managed allocation call site.
- Compare GPU or rendering indicators to form a CPU-wait versus rendering-bottleneck hypothesis.
- Separate GC allocated in frame from Managed Heap size. A heap that stays expanded is not, by itself, proof of a leak.
- Make one change and rerun the same scenario in a Development Build on the target device.
Use Deep Profile last
Deep Profile exposes call detail but adds measurement cost. Use Allocation Call Stacks first when the goal is to find GC allocation sites. Reserve Deep Profile for a short interval that normal profiling and call stacks cannot explain.
Record which scenario changed which portion of frame time, not only that FPS improved.
Official documentation review
Verified
Reviewed against the Unity 6 Profiler documentation. This guide does not present measurements reproduced in a separate project.