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.
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.
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.
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 https://forums.unrealengine.com/showthread.php?49895-Is-casting-expensive: 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++.
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.
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.