Branch cost

What is cheaper: two branches or one branch with AND statement? Could you please explain why?

Here’s an example :

Ah, pic from the short-circuit evaluation thread. Probably the best explanation of the issue ever.

Thank you, mate!

What I mean is, if there’s going to be
something slowing down your code, it
will never be this.

This. It does not matter. If you care about performance, you do not blueprint it.

The second is less lines of assembly code, but even if you had this on tick, you’re not going to notice any difference.

There are many more nodes you could put on tick that would slow things down in a way that did matter.

What I mean is, if there’s going to be something slowing down your code, it will never be this.

There are some nuances, but using multiple branch statements Example 1 has some definite performance gains if your booleans are coming out of “pure” functions.

For example, if you have the case below (image is from Unreal forums):

You have be be careful, because Blueprints will always call “DoSomeExpensiveThing” even if a previous boolean variable was already false (i.e. this is different than C++ which uses lazy evaluation to save performance). In this case, you can avoid an expense function call by using a chain of Branch nodes (Example 1) instead.

That being said, if you are only checking boolean variables directly (no functions), then the performance difference between the two techniques is negligible, and it’s probably best to use Example 2 for improved readability.

Of course, if performance really really matters then doing it in C++ is best.

True, but if we are talking just branches, there’s probably not a lot of difference. Unless the BP interpreter is awful.

Can I use blueprint nativization then? Should it help?

What we’re saying here is that C will beat BP hands down.

But there’s no point in worrying about it if performance isn’t an issue.

That’s what I meant. I agree with you 100% here. There’s so many things to worry about and branch evaluation is not one of them!