This week, I learned a lesson in UE5. I knew blueprints were slow compared to C++, but I didn’t realise how slow. I wrote some functionality that performed sphere casts every x frames. When I integrated it into the game, I lost between 10 and 15 frames. I converted the exact same code to C++; it didn’t even make a dent in the framerate. Here is what I’ve learnt.
What caused it
If you store Actor instances in an array and keep accessing the data… well, that’s very slow in a blueprint. Learning that much of C++ and writing code to handle stuff like this is the way forward. Also, when you get to scripting OnTick, that might be a consideration for C++.
Tracking it down
How do you find problems like this, and when should you optimise? If your change introduces a significant difference in framerate, you should look into it. Unreal Engine comes with Unreal Insights. You can access it from the status bar (at the bottom of the main window). It is your friend. Just hover over a slow frame and you’ll see a breakdown of what’s taking that long. It shows you the Blueprint and function. Very useful. From there, you can devise a strategy to tackle it by fixing a potential problem with the code, changing the algorithm, or changing the language to C++ (and maybe changing the algorithm). Epic has a great resource about this. You can find it on this link.
In general, it’s worth keeping in mind that
- Blueprints are interpreted at runtime, while C++ is compiled into machine code, resulting in faster execution.
- Each Blueprint node execution is slower than a line of C++ code, but the performance difference is most noticeable with many nodes, loops, or nested macros.
- Blueprint ticks can be significantly slower than native ticks, especially when dealing with many instances. Using timers or delegates can mitigate this issue.
- Blueprints introduce a layer of abstraction over the engine’s core functionality, which can lead to slower performance compared to directly written C++ code.
So, when to use which system?
When to Use Blueprints vs C++ (Guidelines)
Consider adding a simple rule-of-thumb table to help readers decide which to use based on complexity/performance:
| Use Case | Blueprint | C++ |
|---|---|---|
| Quick prototyping | ✅ | ❌ |
| Performance-critical logic | ❌ | ✅ |
| Visual scripting for artists/designers | ✅ | ❌ |
| Loops over many actors/tick-based logic | ❌ | ✅ |
Closing words
Many people warn about premature optimisation. But understanding your game’s performance is critical to delivery and can be the foundation for making good design choices and establishing development practices for your team (even if you are a solo developer, eventually, someone else may need to work on your game).
