The performance panel
A live read-out of frame time, and of where GPU, CPU and disk memory are going.
The frame-time graph
The graph at the top plots recent frame times as bars, newest on the right. Each bar is one cook: the samples come from the engine's cook timing, so the graph is empty while nothing is cooking.
Green: 8.33 ms or faster, which is 120 fps.
Blue: up to 16.67 ms, which is 60 fps.
Yellow: up to 33.33 ms, which is 30 fps.
Red: slower than that.
Two faint reference lines mark 16.67 ms and 8.33 ms. A wall of green with the occasional yellow spike is healthy. A solid block of red means something in the graph needs attention.
Watch the graph while you scrub the The timeline or change a parameter. A single tall red bar straight after an edit identifies which edit was expensive to cook.
The metrics rows
Below the graph is a stack of labelled numbers: FPS, Avg, Min, Max, Draws and Tris.
Avg, Min and Max are the average, fastest and slowest frame times in milliseconds across the recent history. A low Avg with an occasional high Max is smooth playback with intermittent hitches. FPS and Max take the same colours as the graph; Min is always green.
Draws and Tris are rows the renderer never fills in. Both read 0 whatever the scene contains.
Lower frame times are better. 16.67 ms is one 60 fps frame, 8.33 ms is one 120 fps frame.
Frame time and cook time are the same measurement here. A heavy simulation or an expensive Expression shows up directly in the graph.
Per-node cost is not in this panel. It is on the hover read-out of a node's output socket, alongside the value's type and element count, and in the Data Viewer.
Memory by tier
Underneath the metrics, memory is broken down by tier, each shown as used / budget with a percentage.
GPU: textures, geometry buffers, render targets, and everything else the renderer holds on the graphics card.
CPU: cached cooks, loaded media, and working data held in system memory.
Disk: the cook-output cache and the compiled-shader cache on your drive. Desktop only, since the browser has no disk tier.
Total: the combined figure across the wired tiers.
A tier turns yellow past 80% of its budget and red past 95%.
The Disk figure is sampled on a background thread every 5 seconds, so it reads 0 for the first few seconds of a session and lags a large cache write. Every row refreshes only when a cook result arrives, at most four times a second, so the numbers hold still on an idle graph.
Each tier is broken down by category behind the scenes, GPU by Textures, Volumes, Splats and the rest, CPU by Image Assets, Video Frames and the rest. None of it is reachable. Nothing in the panel responds to a click, so a tier row cannot be expanded and the breakdown is computed and discarded every refresh.
Pressure badges
The OS Pressure row is a single badge reading Normal, Warning or Critical.
Despite the label it does not report the operating system's own memory-pressure signal. It is computed from how full the budgets above it are, on the same 80% and 95% watermarks. The real OS signal is wired to cache eviction, not to this row, so the badge can read Normal while the machine is under strain.
Which fullness it reads depends on how many tiers are live. On the desktop, where GPU, CPU and Disk are all wired, it pools them and reads the combined used against the combined budget, which is the Total row. Where a tier is missing, as in the browser with no disk cache, it takes the fullest single tier instead so an unwired tier cannot dilute a hot one.
Warning or Critical appearing regularly is a strong signal to lighten the project. See Making it faster and Memory & budgets.
A Critical badge carries a cost. Cached results are discarded to keep going, so cooks that were instant become slow again. Reduce resolution, simplify heavy nodes, or close other apps.