Blueprint best practices for performance?

Hello all,

I’ve been wondering about this as well as searching for answers but haven’t found any, so letme share it.

Does anyone know if there are any best pratices for blueprints? In the sense of getting more performance out of it?

I’m aware that blueprints only have 10% of C++ speed, but how can we get more out of it or at least make it less slower?

Do you have a rule of thumb or trial and error to see how your code performs? Please do share.

Do you have a running project made with blueprints ? Is it slow ?
It cane be several factors affecting game speed like graphic effects, you can’t put all blame on Blueprint and i’m not sure this 10% number is accurate.

I developing a mobile games for now. Haven’t builded it and play tested it on smartphone yet. I’m woried about smartphones processor not being able to handle my project for being made in blueprint.

The idea is to see where people have founds issues that slowed down performance and offer as guidelines to new comers. It would be very handy to everyone i believe.

That ten times slower figure came from a live stream about blueprints, but what they really meant was if you have lots of complex math going on, then you get the worst case scenario of 10x slower. The reason why it is slower is because blueprints runs on a virtual machine, and some nodes require a call to its native c++ code.

Delegates, castes, and interfaces are your most expensive. So just limit those. Simplify your code, and you should be fine. :slight_smile:

The most expensive thing so far would be an unmitigated event tick. That is noticeable right away.

My thinking was that math would be 100% as fast as C++ considering that math is pretty direct.

In the stream they didn’t really say what they meant by math, just that a lot of complex math is what bogs blueprint down. I would imagine that the basic operators would be something that wouldn’t be any problem. Maybe they were talking about doing a lot of stuff in general.

Alright, so if that’s the case. Should Event dispatchers be used in place of BPIs wherever possible?

I am actually still trying to wrap my head around Event Dispatch use versus Blueprint Interface use.

(sorry for the slight derail)

Hi all,

i really got to jump in now that i hear quite often that casting in Blueprints is a performance killer; which is simply wrong.

See It mostly compares Casting vs. Implements Interface checks, but you also get raw numbers. i.e. that one cast costs around 0.4 microseconds. And with looping 10k casts, you still are at 86ms per frame. Of course this is really much, but if you think about it, if you really need to loop even through 1000 objects each frame, you did something terribly wrong, no matter if you are in blueprints or in c++ code.


If I remember correctly from that stream, they mention how blueprint exists on another layer from C++ and every time it runs a node it must go from one layer to another(C++ back to blueprint, and so forth). So basically, if you can perform an action in 3 nodes instead of 6, even if the same amount of stuff is going on among them, then you will be better off.

Another piece of advice would be to use structs to combine data into chunks. Many times you are going to want to pull several bits of data at once and compare them. If you can pull 1 struct and get many bits of data, you are saving a lot of time, especially if this keeps your array checks down to a minimum.

Lastly, I would say that if you have any functions that you use a lot or take up lots of performance, see if you can find away to turn that into a single blueprint node with C++.

Well I do not assume casts to be expensive based on what I’ve heard, but personal experience, while looking at a graph, my FPS jumps when casting, or at least it did in one of my projects.

Excuse my ignorance, but what do you mean when you say unmitigated event tick?

Having multiple things running On Event Tick.

So pretty much every frame that blueprint is running. You don’t want that. Maybe leave it for some Hero assets/functions. Or if you want it to do it for a certain part of the game, use Set Tick Enable/Disables.

If you place a delay node directly after an event tick it slows down the number of ticks to what the delay currently is. So a delay of 0.1 will have a big improvement over attempting to tick every single frame.

If you mean less logic on the event tick only for necessary situation wouldn’t it be better to use a branch node and lock of parts of the code for certain situations?

In fact it would be better to have close to nothing in the Tick event.

Usually people start to do everything in the tick event, since its the only one they know that happens regularly. But the question is if the logic really needs to be executed every frame, or if its enough to be executed every second, or every 0.5 seconds? A looping timer could be used for these things and is most of the times the better choice.
For example, talking about health/stamina/mana/whatever regain. Many people do that in the tick event. After the first time they start their game with a bit higher load on the system they realize that the regain is slower than before -> they take the Delta time into account, add it up each frame and do the regain when the added up delta is >= 1 second. This is a perfect example for a looping timer, that is not influenced by system load / frame rate and doesnt influence the frame rate itself.


If you intend to do very heavy loads, you are going to want to use tick to break that load up over the frames. For instance, I have 2 billion + iterations to run for a standard sized map, and using tick is basically how you do that in a performant way. The same for any other significantly large loops that you want to run without having a spike hit your frame rate. You smooth it out over the frames.

But generally most things don’t need to be updated 30-100 times a second, which is what tick will do if not properly managed.

If you know what you do, most things are legit. But i do dare to say that for 95 percent of the users the golden rule should be to not overuse the tick event :wink:


I personally use Timers for things like regens and UI updates. I reserve Ticks mostly for tutorial lessons and prototyping ideas.

Object Pooling will ensure that the Garbage Collector doesn’t cause framerate issues as well …

There is a primer here that explains it quite well: