Profiling & Frame Budgets

Frame rate is just the inverse of frame time, and turning it into milliseconds is the single most useful mental move in optimization. Sixty frames per second means each frame must finish in 1000/60, about 16.7ms. Thirty fps is 33.3ms; 90fps - the comfortable floor for VR - is 11.1ms; 120fps is 8.3ms. That number is your budget, and everything the frame does has to fit inside it: game logic, animation, physics, culling, issuing draw calls, and the GPU actually drawing the pixels.

Working in milliseconds beats working in fps because milliseconds add up linearly and fps does not. Going from 60 to 50fps sounds small but is +3.3ms; going from 30 to 20fps is a huge +16.7ms. When you shave a feature that costs '2ms', you can add that straight into your budget arithmetic. Frame rate figures hide this; millisecond figures make optimization a spreadsheet.

VR makes the budget unforgiving in two ways at once. It demands a higher frame rate (90fps and up, so a shorter budget), and it renders the scene twice, once per eye. So the VR frame budget is not just tighter - it is tighter while doing roughly double the work. That is why Module 9's last lesson treats VR performance as its own discipline; here, just hold the numbers: 16ms desktop, 11ms VR, and VR pays it twice.

The fastest way to see the budget in Unreal is the stat console commands. Press the backtick key to open the console and type stat fps for a frame rate and frame time readout, or better, stat unit - the single most important profiling display you have. It shows four numbers in milliseconds: Frame (the total), Game (the CPU game thread - your Blueprints, logic, animation, physics), Draw (the CPU render/draw thread - preparing and issuing draw calls), and GPU (how long the graphics card took to draw the frame).

Read them together and the scene tells you where it hurts. The three workers - game thread, draw thread and GPU - run largely in parallel, so your frame time is set by the slowest of them, not their sum. If Frame is 21ms and GPU is 12ms while Draw is 20ms, the draw thread is your wall. Cut the GPU cost and nothing improves, because the draw thread was already the long pole.

Add stat unitgraph to see those numbers plotted over time, which exposes spikes a single reading hides - a stutter every few seconds usually means something intermittent (garbage collection, a level stream, a heavy Blueprint tick). stat rhi reports the raw draw-call count and triangles drawn this frame, the two numbers you most often need when the draw thread is the problem. Learn these four commands and you are already ahead of most people optimizing by feel.

Almost every optimization decision hinges on one diagnosis: are you CPU-bound or GPU-bound? Optimize the wrong side and you spend hours for no frame-rate gain, because you were never touching the bottleneck.

The read from stat unit is direct. If GPU is the largest number and close to Frame, you are GPU-bound - the graphics card is the wall. Fixes live on the pixel side: lower the resolution or resolution scale, reduce shadow quality, dial down Lumen (global-illumination) cost, simplify materials and translucency, cut post-processing. If instead Game or Draw is the largest, you are CPU-bound. A high Draw points at too many draw calls - the CPU is spending its time describing thousands of separate objects to the GPU - so you instance, merge and cull (the next lesson). A high Game points at expensive logic - heavy Blueprint ticks, physics, animation - so you optimize or throttle that code.

A useful confirming trick: the console command r.ScreenPercentage 50 roughly halves the pixels the GPU draws. If your frame rate jumps, you were GPU-bound; if it barely moves, the GPU was never the wall and you are CPU-bound. This one-line test cuts through a lot of guessing. Diagnose first, then reach for the matching fix - never the other way around.

When stat unit tells you which worker is slow but not why, two deeper tools break the frame open. The GPU Visualizer (ProfileGPU, bound to Ctrl+Shift+comma by default) captures a single frame and shows a breakdown of GPU time by pass - base pass, shadows, Lumen, translucency, post-processing - so a GPU-bound scene reveals exactly which pass is eating the budget. If shadows are 4ms and Lumen reflections are 3ms, you now know precisely where to spend your effort.

For the CPU side and for intermittent problems, Unreal Insights is the professional-grade tool: it records a full timeline trace of the game and render threads, letting you zoom into a specific hitch and see which functions, Blueprints or systems consumed the time. It is heavier to set up than a stat command, but it is how you catch the once-a-second spike that stat unit only hints at.

Build the habit as a ladder. Start with stat unit for the one-glance diagnosis; add stat rhi for draw calls and triangles; run r.ScreenPercentage 50 to confirm CPU-versus-GPU; open the GPU Visualizer to find the guilty GPU pass; and reach for Unreal Insights when you need a full trace of a hitch. Measure, form a hypothesis, change one thing, and measure again. That disciplined loop - not blanket setting-lowering - is what separates real optimization from cargo-cult tweaking, and it is the mindset the rest of this module puts to work.

Put it together with a concrete example, because the whole skill is translating a reading into a decision. You open a heavy interior scene, press backtick and type stat unit. It reports Frame 24.0ms, Game 8.5ms, Draw 23.2ms, GPU 13.0ms. First, convert Frame to fps: 1000 / 24 is about 42fps - well short of your 60fps (16.7ms) target. Second, find the long pole: Draw at 23.2ms is by far the largest and sits right under Frame, while GPU is only 13ms. That single comparison tells you the story - you are CPU-bound on the draw thread, and the GPU has spare capacity.

You confirm it in one line: type r.ScreenPercentage 50 to roughly halve the pixels the GPU draws. The frame rate barely moves - proof the GPU was never the wall. Set it back to 100. Now type stat rhi: it reports something like 9,400 draw calls. That number is enormous for an interior and explains everything - the scene was imported piece by piece, so the CPU is spending its whole budget describing thousands of separate objects. Your plan writes itself: instance the repeated furniture and fittings, merge the fixed clusters, and consolidate materials. None of it touches resolution, shadows or Lumen, because those live on the GPU side you already ruled out.

Contrast the opposite reading. If stat unit had shown Frame 20ms, GPU 18ms, Draw 6ms, and r.ScreenPercentage 50 had leapt the frame rate, you would be GPU-bound, and the GPU Visualizer would tell you whether shadows, Lumen or translucency was the culprit. Same tools, opposite conclusion, opposite fix. That is why the reading comes before the wrench every single time - the numbers, not your instinct, choose the lever.