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:
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:
However, in cases like this:
Set Speed
and Set Is Moving
nodes.
In your specific example, the Get Controlled Pawn
function is this:
@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.
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
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