Do functions and macros affect performance when cleaning the event graph?

So basicly connecting 5 macros in a row, is like having no macros just nodes?

How the title says, will it affect performance if i wrap a feature(see image) into a macro or function to cleanup the even graph?

For example this…

…is stopping my plane.
I can’t really wrap it into a function because the booleans look like they reset on each call to the “default” or something.

I mean it will be used only once a time to stop the plane to check something.
There will be more and more features on the plane, so i don’t want to get messy in the event graph.

Macros are code pastes they should not effect performance in any way compiler pasted content of macro to place of macro, functions may but not in noticeable way or else you do loopy code.

yes, that is correct, connecting 5 macro’s will just expand to the nodes that they represent.

Basically the breakdown would be like this.

  1. Macros - these are for your convenience only, for a set of nodes, that should be too few to actually justify creating a function. For example, a macro that will test two Boolean values, and then feed the AND/OR of the two Booleans into an IF node, and then take the appropriate output based on the two inputs. This would reduce the node count by 1, as well as make the code a lot easier to read.

Versus

  1. Functions - those pieces of code that need to be invoked from multiple places, and are much larger in size. For most languages, it’s a matter of Size of the actual code as to whether it should be in a macro or function (note that I am totally ignoring inline functions, which blueprints does not support to my knowledge). But back to blueprints, suppose you wish to have a function/macro, that will set materials and material parameters for any static mesh, as well as do decent error reporting, etc. Then this probably best put into a function library (note: that blueprints also support Macro Libraries as well), so that you can reuse it among all your blueprints. Instead of having it expand for each invocation, as a macro would do.

Finally note that another difference between macros, and functions in Blueprints, is the creation of local variables, is much trickier in a macro than it is in a function.

With all the above said about size, in my carreer I have created macros in assembler that exceeded 2000 lines of macro coding, but this was due to wanting to preprocess the input before the assembler got ahold of the code. So there are not hard and fast rules, for functions versus macros. But the size of the code, and the number of local variables you will use, is a very good indicator as to which way you should go.

Hope this helps,

Local variables begin to exist when the function starts executing, and only exist within that function, execution. Once the function returns or breaks/exits, then the local variables cease to exist. ( although I believe any out-parameters they passed their values into will return out to the scope of whatever called the function. Just make sure the out parameters are not a reference or pointer to the local variable rather than a copy of their value, or they’ll be referring/pointing to a now-nonexistent memory location.