Chapter 11

Ticking & Performance

How to diagnose a performance problem, what Tick and spawning actually cost, why Blueprint makes it worse, how to tier tick rates, and the event-driven alternatives.

In this chapter

  1. Diagnosing a Performance Issue
  2. The Cost of Tick
  3. Blueprint vs. C++ Tick Cost
  4. Reducing Tick Frequency
  5. Disabling Tick
  6. The Cost of Spawning and Despawning
  7. Event-Driven Alternatives
1

Diagnosing a Performance Issue

A repeatable workflow, before touching tick rates or spawn costs:

Frame:  28.5 ms
Game:   28.1 ms
Draw:    6.4 ms
GPU:    11.2 ms

Frame tracking Game closely, with both well above Draw and GPU, points at the CPU game thread — not rendering.

Once the bottleneck is located, investigate the specific systems in that area rather than guessing across the whole codebase.

2

The Cost of Tick

Tick runs every frame for every actor and component that has it enabled. Cost scales with count multiplied by per-frame work, so thousands of ticking actors — especially in Blueprint — is a classic performance killer.

The habit to build is asking "does this actually need to run every frame?" Most gameplay logic is event-driven, not continuous.

3

Blueprint vs. C++ Tick Cost

Both tick once per frame by default — the same frequency. The difference is overhead.

Blueprint Event Tick runs through the Blueprint VM, a bytecode interpreter, making it roughly 10–50× slower than equivalent C++ for the same logic. The cost comes from per-node virtual calls, parameter marshaling, and graph traversal.

So keep any genuinely per-frame work in C++, not Blueprint.


4

Reducing Tick Frequency

// C++ constructor
PrimaryActorTick.TickInterval = 0.1f; // ~10x/sec instead of every frame

In Blueprint: set ActorTickInterval in the Details panel, or call Set Actor Tick Interval at runtime.

The interval is a minimum, not precise timing. If a frame runs long, it just ticks next frame.

A tiered approach for AI

RateWhat belongs there
Every frameThings the player directly perceives — traces, movement
0.1–0.2sPerception checks, threat assessment
0.5–1.0sSquad coordination, pathing decisions
2–5sAmbient and idle-state decisions

5

Disabling Tick

PrimaryActorTick.bCanEverTick = false;   // constructor — never registers
SetActorTickEnabled(false);              // runtime toggle

bCanEverTick = false is cheaper than a runtime toggle, because the actor is never registered with the tick system at all — there's nothing to skip over each frame.

Disable tick when it isn't needed, rather than leaving it on by default.


6

The Cost of Spawning and Despawning

Spawning and despawning actors is expensive in its own right, separate from tick cost:

Despawning a lot of actors in a short window can make the garbage collector stutter or hitch — the same GC pass that keeps references safe has a real cost when it's asked to reclaim a burst of objects at once.

Pooling — reusing actors instead of destroying and respawning them — sidesteps all four costs at once, which is why it shows up so often for anything spawned in volume: projectiles, VFX, enemies.


7

Event-Driven Alternatives

Prefer reacting to events over polling every frame:

An AI-specific pitfall. Behavior Tree tasks and services already have their own tick and interval systems. Piling expensive logic into Event Tick on top of them is a common and avoidable perf problem.

Interview drill

Answer out loud before re-reading the chapter.

  1. What is the cost of Tick, and how do you avoid overusing it?
  2. How do you diagnose a performance issue, and what does stat unit tell you?
  3. Why is spawning and despawning actors expensive, and what mitigates it?
← Chapter 10 ↑ Index Chapter 12 →