# 1. Profiler Window and a Repeatable Workflow Part of [[Profiling and Optimization]]. Next: [[2. CPU Allocations and Incremental GC]]. > [!note] Verification status > Profiler and Frame Debugger live under **Window > Analysis** in the 6000.5 manual. Development Build / Autoconnect Profiler are the standard Build Profile flags for attaching to a Player (also described in Meta's Unity performance page). **Not verified:** every module name in the 6000.5 Profiler module dropdown. **No live capture was taken for this write-up.** ## 1.1 The only workflow worth teaching 1. **Pick a target.** Editor Play Mode is for finding *where* to look, not for signing off. Sign off on a **Development Build** of the platform you ship (Windows player, or a Quest 2 headset for VR). 2. **Pick a scene and a verb.** "The camp at dusk, walking from the gate to the well, no menus." Write it down. A capture without a verb is a souvenir. 3. **Take a baseline** (30-60 seconds, or a few hundred frames). Save the capture. 4. **Change one thing.** Rebuild if needed. 5. **Take the same verb again.** Compare (Profile Analyzer, part 5). 6. **Stop when the budget is met**, not when the graph looks prettier. If you cannot say the verb and the budget ("72 FPS on Quest 2, walking the courtyard"), you are not profiling yet. ## 1.2 Open the Profiler **Window > Analysis > Profiler**. The window can attach to: - The **Editor** (Play Mode) - A **Player** started as a Development Build, optionally with **Autoconnect Profiler** enabled in the Build Profile - A device over USB / Wi-Fi (Android / Quest: enable development build, open the Android profiler connection; see [[4.Quest 2 Testing and Deployment]]) For a first class demo, Editor Play Mode is fine. For any number you will defend, use a Player. The Editor is busy with inspectors, asset importing and your second monitor; its CPU times are not your game's CPU times. When you build: - Enable **Development Build**. - Enable **Autoconnect Profiler** if you want the Profiler to hook in on launch (Meta documents this for Link and for standalone Quest). - For GPU data on device, you also need the platform's graphics profiler support; the CPU modules work first and are already enough to find most student-project issues. ## 1.3 What you are looking at A Profiler capture is a timeline of **frames**. Click a frame, then read the modules you enabled: - **CPU** — where the main thread and job worker threads spent the frame. This is the default first stop. - **GPU** — how long the GPU took, when the platform can sample it. Use it with the Frame Debugger (part 4), not instead of it. - **Memory** — a high-level view; the Memory Profiler package (part 3) is the real memory tool. - **Rendering** — batches, setpass calls, triangles (useful, but the Frame Debugger tells you *which* draws). - **Audio**, **UI**, **Video**, and others as needed. Disable modules you are not using. Each module has a cost, and a crowded window hides the spike you came for. On the CPU module, learn to read: - **PlayerLoop** / **Update** / **LateUpdate** / **FixedUpdate** — your scripts - **Animation**, **Physics**, **UI Toolkit** or **uGUI** — systems - **GC.Collect** or a garbage-collector marker — a hitch waiting to happen (part 2) - **Gfx.WaitForPresent** / waiting on the GPU — you are GPU-bound or waiting for vsync; the CPU graph alone will mislead you ## 1.4 Deep Profile and managed call stacks **Deep Profile** instruments every managed method. It is heavy. It changes timings. Use it to *find a method name*, then turn it off and measure again with a `ProfilerMarker` around that method (part 2). **Call Stacks** (allocation call stacks) tell you *who allocated*. Enable them when you are hunting GC, not for a baseline FPS capture. Neither belongs in a "this is our frame time" recording. ## 1.5 Editor Play Mode vs a Player, in one sentence Use Play Mode to form a hypothesis ("the inventory rebuild allocates every time I open the menu"). Use a Development Build to accept or reject it. Quest work always finishes on a headset; Meta says to lock CPU/GPU levels before you compare two Quest captures, otherwise thermal or clock changes look like a regression. ## Official docs - Profiling tools reference: https://docs.unity.com/en-us/engine/6000.5/manual/analysis/performance-profiling-tools - Meta testing and performance analysis: https://developers.meta.com/horizon/documentation/unity/unity-perf/