You keep placing assets in your level, and at some point the motion starts to stutter. You weaken the shadows and lower the texture resolution, and not much changes. Before touching more settings, look at which work is taking the time.
UE5's stat unit is a command that prints the whole game's time and the time of its main workers on screen. It gives you a first clue about where to start: the CPU game work, the CPU render preparation, or the GPU.
This article organizes how to read those numbers, then toggles Tick on a rotating Actor to compare. The goal is not to hit a specific number, but to measure under the same conditions, change one thing, and be able to explain the difference .
What You'll Learn
- The difference between FPS and frame time
- How to read Frame, Game, Draw, and GPU, and how far they let you conclude
- Why FPS caps and measurement conditions have to match
- How a small comparison experiment points you at the next place to look
The hands-on uses Blueprint creation, adding a Component, and connecting nodes. The measured values in the diagrams and tables are examples for explaining how to read them. Real values change with your PC, your settings, and your UE version.
Seeing "heavy" in milliseconds
The same word "stutter" can come from many places: behavior calculations for a crowd of enemies, overlapping translucency, asset loading. Measuring first lets you decide whether you need to lower visual quality or investigate the game logic.
FPS is how many frames get displayed per second; frame time is how long one frame took. When comparing cost, frame time in ms (milliseconds, one thousandth of a second) is easier to work with.
The rough conversion is frame time = 1000 / FPS.
| Target | Rough time per frame |
|---|---|
| 30 FPS | About 33.3 ms |
| 60 FPS | About 16.7 ms |
| 120 FPS | About 8.3 ms |
120 to 60 FPS is about 8.3 to 16.7 ms; 40 to 30 FPS is 25 to 33.3 ms. Both are an increase of about 8.3 ms in frame time, but the FPS drop looks very different. Recording how many ms you removed , not only "how many FPS it gained", makes changes easier to compare.
Also, even at an average of 60 FPS, a single frame that occasionally takes 100 ms will catch. A moment where processing time jumps is called a spike . Investigate "heavy the whole time" and "freezes for an instant" separately.
Show stat unit and learn who does what
Press Play in your current level and click the game window. Open the console, type stat unit, and press Enter. The console is a field where you type short commands to inspect game state or change settings.
The default key is the backquote, but on some keyboard layouts it will not open. In that case go to "Edit → Project Settings", search for Console Keys , and add an unused key. The setting lives under "Engine → Input → Console". Play again after setting it.
Once numbers appear, look at these four rows first. Typing stat unit again hides the display.
| Row | How to read it at first |
|---|---|
| Frame | Time for the whole frame. The entry point for whether you are hitting the target |
| Game | CPU game thread time. Game progression, Actor updates, and so on |
| Draw | CPU render thread time. Preparing and assembling draw commands |
| GPU | Time the GPU spent drawing the screen |
The CPU handles game progression and general calculation; the GPU is the part that excels at the large volume of calculation drawing needs. A thread is a flow of execution that runs work in order. Here it is enough to think of it as "the one advancing the game" and "the one preparing the drawing", both on the CPU side.
It matters that you do not confuse Draw with GPU time. And 1000 objects do not automatically become 1000 draw commands. Materials, the rendering path, and mechanisms that batch identical objects all change that.
Frame is not the sum of Game, Draw, and GPU
These workers advance work for different frames in parallel. While the GPU draws one image, the CPU side can prepare the frame after it. Overlapping stages like this is called pipelining .
For example, with Game 5 ms, Draw 4 ms, and GPU 15 ms, you do not read Frame as a simple sum of 24 ms. The GPU becomes the candidate limiting overall speed. Such a limiting point is called a bottleneck .
That said, waits and other work are also involved, so Frame does not match the maximum value exactly . stat unit is the entry point for narrowing down a worker. It is not a tool that confirms a specific Actor or function from a single number.
Match your measurement conditions
If the camera angle or the resolution changes between the before and after, so do the visible objects and the number of pixels drawn. To avoid mistaking that difference for the effect of your fix, match the following.
| What to match | How we decide it here |
|---|---|
| Launch method | Launch Standalone Game from the "Play" menu |
| Screen | Same window size, resolution, and quality settings |
| Scene | Start from the same Player Start and face the same way |
| Measurement start | After loading and shader compilation have settled |
| Observation time | The same duration every time, roughly a few to ten seconds |
Standalone Game runs the game in an independent window. PIE (Play in the editor) shows the trend too, but the editor's own work mixes into the measurement. For a pre-release check, packaging a Development build and measuring on the target PC gets you closer to the real environment.
If it pins near 60 FPS, check the caps too
Vertical sync (VSync) aligns display with the monitor's refresh. Even with headroom, it can wait for that refresh. An FPS cap is likewise a setting that refuses to run faster than a certain rate.
Sitting near 60 FPS does not immediately mean the GPU is at its limit. When you want to compare with waits excluded, check and note the current values in the launched game's console, then change them.
| Input | Meaning |
|---|---|
t.MaxFPS | Show the current FPS cap |
r.VSync | Show the current VSync setting |
t.MaxFPS 0 | Remove the limit from this cap |
r.VSync 0 | Turn off VSync on the game side |
t.MaxFPS 0 alone does not disable VSync. Smooth Frame Rate and Use Fixed Frame Rate under "Project Settings → Engine → General Settings → Framerate", plus caps in your GPU driver, are separate again. Record the original settings if needed and remove them only while measuring. Restore them when you are done.
Match these settings across both states you are comparing. Do not count the act of removing a cap as an optimization result for your game.
Choose the next place to look from the numbers
Look at whether Frame exceeds your target first, then compare Game, Draw, and GPU. The worker producing a large value close to Frame is your investigation candidate.
| Example for explanation | What to check next |
|---|---|
| Frame 22.5 / Game 21.4 / Draw 8.2 / GPU 12.1 ms | Game is large. Break down Actor updates, AI, and so on |
| Frame 22.5 / Game 5.0 / Draw 4.0 / GPU 21.4 ms | GPU is large. Find which rendering work is taking long |
| Frame 16.7 / Game 4.0 / Draw 3.0 / GPU 5.0 ms | The main work has headroom. Check caps, waits, other workers |
If Game and Draw are close, do not mechanically declare one of them the cause. Waiting between workers can be involved. Look at the breakdown, pick one candidate, and confirm what drops when you change that work.
Even when you meet the target, check separately for heavy scenes and spikes. On the other hand, if you already meet the target you need, there is no reason to keep cutting endlessly just because something "is the biggest right now".
Tools for one step deeper
Do not display all of the following at once. Use whichever matches your candidate.
| Where to investigate | Tool | Clue |
|---|---|---|
| Game | stat game | Time per game-work category, such as Tick |
| Draw | stat scenerendering | Processing time and counts related to rendering |
| Deciding what is visible | stat initviews | Time judging draw targets, how many were excluded |
| GPU | stat gpu, profilegpu | Time per rendering stage, such as shadows and lighting |
| Momentary hitches | stat unitgraph, Unreal Insights | The shape of the change, and a record of when it happened |
Tick is update work called every frame. If Tick-related rows in stat game are large, look not only at how many Actors run it but also at how much each call does. Even a few Actors take time if each one searches a large array every frame.
A draw call on the rendering side is a call requesting drawing work. Do not judge by count alone; read it together with before-and-after time in the same scene. Culling removes invisible objects from the draw set. It is a clue before you move on to the LOD and culling article.
A GPU pass is one stage of rendering. If shadow-related time is large, for instance, investigate the lights casting them, their targets, and their settings. Depending on your UE version and environment, profilegpu results appear in the GPU Visualizer window or in the Output Log. If no separate window appears, check the log first.
Unreal Insights records processing and lets you read it along a timeline afterwards. When numbers are close and you cannot separate causes, or for a problem like "it only freezes the moment an enemy appears", move on to recording with the Insights article.
Hands-On: toggling Tick on a rotating Actor
Place several rotating props and run an experiment that keeps the placement identical and compares having the rotation work or not . Stopping rotation is a way to investigate the relationship between work and cost. It also stops motion the game needs, so this change is not the finished version.
1. Make one rotating Actor first
Use a Third Person Blueprint project. From the Content Browser, create a Blueprint with Actor as its parent and name it BP_Spinner.
| Where to set it | Value |
|---|---|
| Component to add | Static Mesh Component, named SpinnerMesh |
| Static Mesh | The engine's basic Cube shape |
| SpinnerMesh Scale | X=1.0, Y=0.2, Z=0.2. A long thin shape so rotation reads |
| Mobility | Movable |
| Collision Presets | NoCollision |
| Simulate Physics / Cast Shadow | Both off |
| Class Defaults → Actor Tick | Start with Tick Enabled on, Tick Interval 0.0 |
If you cannot find Cube, show Engine Content in the asset picker. With Tick Interval at 0, it updates every frame while Tick is enabled.
In the Event Graph, make the following connections. Multiply is multiplication, and Make Rotator gathers three axis angles into one rotation amount.
- Event Tick's white exec output → Add Actor Local Rotation's exec input.
- Event Tick's Delta Seconds → one side of Multiply. The other side is 90.0.
- Multiply's result → Make Rotator's Z (Yaw). X (Roll) and Y (Pitch) are 0.
- Make Rotator's Return Value → Add Actor Local Rotation's Delta Rotation. Target is Self; leave Sweep and Teleport off.
The diagram is a schematic showing what the connections mean. The top row is the flow of execution; the bottom row is the rotation-amount calculation. Target Self means this Blueprint's own Actor.
Delta Seconds is the elapsed seconds since the previous update. Multiplying by 90 gives "this frame's rotation amount" for turning 90 degrees per second. Yaw is rotation around the vertical axis.
Compile, place one in the level, and move it above the floor. Play, and if it spins sideways, one unit is done. If it does not turn, check the white exec wire, Movable, and the Tick settings.
2. Increase the count and record the "before"
Stop, then duplicate the placed BP_Spinner with Alt+drag. You can select a group and duplicate it all at once. Spread them across the floor with gaps and start with about 32.
The count is not a fixed reproduction condition. If 32 does not show a readable difference, you can step up to 128 or 512, but there is no need to force it below 60 FPS. A result saying "rotation work of this scale is not the main load on this PC" is fine too.
Match the conditions described earlier and launch Standalone Game. Stand still at the same starting position and display stat unit and stat game. After loading settles, watch for about 10 seconds and record the approximate range plus any large jumps.
| Record field | Write your own values |
|---|---|
| Conditions | Actor count, resolution, quality, launch method, cap settings |
| Tick on | Frame / Game / Draw / GPU, and Tick-related time |
| Tick off | Same rows |
| Tick back on | Did the same trend return |
3. Turn off only Tick and compare
Quit the game and turn off Start with Tick Enabled in BP_Spinner's Class Defaults. Do not change the number of placed Actors, the material, or the camera. Compile, save, and launch under the same conditions.
Confirm the props no longer rotate, then read the same roughly ten-second range. Finally turn Tick back on and measure once more. Watching whether the trend returns across on, off, and on again makes it easier to separate a real effect from a run that just happened to be light.
4. Think about what the numbers told you
The following is a comparison example for explanation. It is not measured from this number of BP_Spinners.
| Row | Tick on example | Tick off example |
|---|---|---|
| Frame | 22.5 ms | 12.8 ms |
| Game | 21.4 ms | 4.1 ms |
| Draw | 8.2 ms | 8.0 ms |
| GPU | 12.1 ms | 12.0 ms |
In this example, you can conclude that updating the rotating Actors was heavily involved in Game time. But stopping rotation also removes work such as reporting position and orientation changes to rendering. You cannot read the difference as "time spent only on the Blueprint nodes".
Other results are clues for investigation too.
| Change you saw | What to consider next |
|---|---|
| Both Game and Frame dropped | The work you stopped is a candidate for limiting overall speed |
| Game dropped but Frame barely moved | Check whether the GPU, another worker, or an FPS cap is the limiter |
| Game barely moved either | Small difference, other work is larger, or Tick is not actually off |
| Draw or GPU changed a lot too | Include the rendering change from stopped rotation in the comparison |
| Turning it back on does not restore | Re-check loading, viewpoint, settings, and other running apps |
Build the real fix while keeping the behavior you need
Once you have narrowed the candidates, reduce work while keeping the motion the game needs. Ask whether distant decorations can stop updating, and whether you can split work that truly needs every frame from work that can run less often.
Simply replacing a rotation animation with a low-frequency Timer can make the motion look choppy. Rather than avoiding Tick across the board, fix it to fit the use case using Tick versus Timer as a reference.
After the fix, measure again under the same conditions and check the controls and appearance as well. Even if Game drops and the GPU becomes the largest, whether to cut the GPU further can be decided from what the game actually needs.
Bonus: Good to Know Up Front
Watch the shape of the change, not only the number
stat unitgraph shows variation over time as a graph. It suits telling "high the whole time" from "spikes for an instant". The normal display smooths values, so record with Insights when chasing short spikes in detail.
Streaming is the mechanism that loads data as it becomes needed. stat streaming is a clue for things like texture memory use. The display alone does not confirm "this load is the cause of the freeze". Record when the loading happens, then consider measures like soft references and async loading.
If RHIT or DynRes shows up
RHIT is time on the RHI thread, which hands draw commands to the graphics API. If it is large, investigate that worker and its wait time. There is no need to force it into the three-way Game / Draw / GPU choice.
DynRes relates to dynamic resolution and is a percentage of render resolution, not milliseconds. Also, some environments cannot report GPU time. Do not read a blank or missing row as "zero GPU load".
Clean up the display and restore your settings
The stat commands toggle when typed again. stat none clears the displays together. After the experiment, restore settings you changed for measuring, such as the FPS cap, VSync, and Smooth Frame Rate.
Next time you hit a heavy scene, look at Frame first, narrow the worker candidates, and change one condition to compare. Even if the number does not drop as expected, learning "this work alone cannot explain it" lets you pick the next place to look.
Summary
- FPS is "how many images per second", frame time is "how many milliseconds per image". Compare the time
- Which of Frame, Game, Draw, and GPU is thickest decides where to look next
- Without matching caps and measurement conditions, before and after cannot be compared
The question to ask before measuring is "what exactly am I comparing to what?" . Change one condition at a time and the cause narrows to one.
To dig deeper go to Unreal Insights; to reduce rendering work go to LOD and culling.
Reference: Stat Commands, Introduction to Performance Profiling, General Engine Settings, Console Variables Reference.