Example: I will deliver an input axis event to the currently controlled pawn. Is it any difference if I cached a reference to the pawn, like this:
compared to:
Depending on the situation and the function called, yes it can make a difference, sometimes quite big. In general when it comes to blueprints there is always a small overhead when executing nodes, but most times it’s negligible.
On another note, pure functions get called once for every connection of their output pins, which is important and can make a difference in the result of your function.
Take the following example:
This function will not give you the result you might expect, since the Random Float In Range node will get executed twice, once for the comparison and the branch, and once for the print string. And since it generates a random number every time it’s run, a different number than the one used in the comparison will be printed. So in this case you need to cache the result like so:
So if you take that into consideration, especially when it comes to some pure functions like for example:
which could potentially be expensive or slow, then it makes sense to cache the result, if you are using it multiple times and it doesn’t change in between.
However, in cases like this:
where you need to access a value that is changed and you need the latest value, then caching won’t help you.
In this example however, it would be more efficient to do this:
than this:
especially because it would have to calculate a vector length twice, which uses a square root, which is a generally expensive function for computers, even though the vector doesn’t change between the
Set Speed and Set Is Moving nodes.
In your specific example, the Get Controlled Pawn function is this:
so it’s basically just a getter for the internal variable “Pawn”, so the only price you’re paying is the small overhead of blueprint nodes. But still, be mindful when using pure functions like that, and of course if you are planning to reuse something it’s always better performance wise to cache it, but at the same time you shouldn’t stress too much about it unless it’s the result of an expensive call
6 Likes
@zeaf , just the sort of explanation I was hoping for + more. Very helpful, thanks a lot.
zeaf’s explanation should be in the official documentation for blueprints.
3 Likes
This drove me crazy for a long time!
Blueprint scripting looks like a dataflow, functional graph, but it’s actually a graph encoding of a procedural program. The same “pure” node going to two different execution nodes, will be evaluated twice, meaning the same “pure” reference may return different values to the different readers.
This really needs to be put front and center in the blueprint reference documentation, at least for programmers who aren’t new to programming.
(I still get confused sometimes!)
Or, to put it in terms a functional programmer might want: Each white “exec” node is a separate monadic bind operation, and “pure” only holds within each such operation. And even there, it’s not actually pure – it can get evaluated multiple times, which matters if the internal implementation actually mutates something, like incrementing a counter. So, a “pure” blueprint node is less like pure and more like unsafePerformIO 
2 Likes
i saw this recently, it has a nice collection of little tips. Seems like the intent is to startup a new wiki, and it looks like they have some megagrant support.
Might be worth trying to add a “blueprint pure functions, beware!” tip about this. I’m happy to transpose what I learned here but probably better if a real programmer who can explain more correctly did so.
Of course, it does belong in docs, but I dunno if that even gets more eyes than some of our community resources