Information

Construction Scripts are useful for automatically setting up Blueprint Actors and previewing their result directly in the editor. However, it is important to understand that their logic is not necessarily executed only once when you initially place an Actor.

Unreal Engine can reconstruct Blueprint Actors while working in the editor, causing their Construction Scripts to execute again. If a level contains many Actors with expensive Construction Scripts, this can add a significant amount of unnecessary work.

Prefer watching a video instead? Check out our Video Tutorial on this topic.

Construction Scripts can run when loading a level

When Blueprint Actors are loaded and added to the editor world, Unreal Engine may rerun their Construction Scripts to make sure their generated components and properties match the latest version of their Blueprint.

This means that opening a level containing a large number of Blueprint Actors can involve more than simply loading their saved data. Construction Script logic may also need to be executed as Actors are reconstructed in the editor.

Every Actor adds more work

The cost of a small Construction Script might not be noticeable on a single Actor. However, that cost can quickly increase when hundreds or thousands of instances exist inside a level.

For example, if you have 500 Actors using the same Blueprint, expensive construction logic may need to be performed across many of those instances when the level is loaded or reconstructed.

Reconstruction can recreate components

Rerunning a Construction Script is not always as simple as executing a few Blueprint nodes again. Unreal Engine can destroy components that were automatically created during construction and recreate them as part of the reconstruction process.

Blueprints that generate large numbers of components, perform procedural generation, run large loops, perform traces, or process large amounts of data can therefore become especially expensive to reconstruct.

They also run while editing

Level loading is not the only time Construction Scripts can execute. Unreal Engine can also run them when you change properties or transform an Actor inside the editor.

This is why an Actor with a heavy Construction Script can feel slow when you move it around the viewport or adjust one of its settings. A single change can cause the Actor to be reconstructed and its Construction Script logic to run again.

Be careful with procedural generation

Procedural systems are particularly easy to make expensive inside a Construction Script. Generating meshes, creating large numbers of components, performing many traces, or iterating through large collections can be convenient because the result appears directly in the editor.

However, if that work is repeated whenever the Actor is reconstructed, the convenience can come at the cost of slower level loading and worse editor responsiveness.

Construction Scripts and packaged projects

The performance concerns described above are primarily related to working inside the Unreal Editor. Construction Scripts can run repeatedly while loading levels, moving Actors, changing properties, or reconstructing Blueprint instances, which can make the editor feel slow.

For Blueprint Actors that are already placed in a level, their constructed result is baked into the packaged level during the cooking and packaging process. Their Construction Script does not need to repeatedly run simply because the packaged game starts, so an expensive Construction Script on placed Actors does not automatically translate into the same performance cost during gameplay.

Actors that are spawned dynamically at runtime are different. These Actors still go through their construction process when they are created, so expensive construction logic can still have a runtime cost if you spawn many of them during gameplay.

In other words, the main issue discussed here is editor performance. Heavy Construction Scripts on placed Actors can make level editing and loading slower, but that repeated editor reconstruction cost is not carried over in the same way to a packaged game.

Alternative approaches

If a Construction Script becomes too expensive, consider moving the work to a system that gives you more control over when it runs. Depending on what the Blueprint is doing, there are several alternatives that can reduce unnecessary reconstruction work while still keeping the workflow convenient for level design.

  • PCG Framework: Unreal Engine's Procedural Content Generation framework is a good alternative for procedural placement and generation. It is designed for larger procedural workflows and provides better control over when content is generated or refreshed.
  • Editor Utility Blueprints: Move expensive editor-only operations into an Editor Utility Blueprint so the work only runs when you explicitly trigger it.
  • Callable functions or custom events: Put expensive generation logic inside a function or event that can be executed manually when the result actually needs to be rebuilt.
  • Pre-generated or baked data: Generate complex results once and save the resulting components, meshes, or data instead of rebuilding them every time the Actor is reconstructed.
  • Runtime generation: If the generated content does not need to be visible while designing the level, consider creating it during gameplay instead of inside the Construction Script.
  • Move heavy construction logic to C++: Expensive calculations, large loops, and data processing used by a Construction Script can be moved to C++ and executed from OnConstruction(). This can significantly reduce the cost of CPU-heavy logic compared to performing the same work entirely in Blueprint.

In general, use Construction Scripts for lightweight, frequently updated setup and move heavier generation work to systems that let you decide when regeneration should happen.