What is the tick cost associated with "exposing as pin" in an animation blueprint?

[Killerbanaple]

If I expose a variable (as shown in the screenshot below), will this permanently require tick updates? Does it only update if the value is changed and no tick is involved? Does it update on tick but only when the state machine is in that current state? I know binding in a widget does involve constant tick updates regardless, but the way the ABP expose variable is setup is different which makes me think it might function differently as well.

Background:

I am using animation layer interfaces to break up item animations into unique animation blueprints. I have a main ABP with my character skeleton that implements my animation layer interface and has no code, just plugs the ALI into the output pose. The input coming from the linked ABP is the entire state machine. Since anim layer interfaces can’t be overridden in child ABPs and I don’t want to have to update my ABP logic individually for every item each time I make a change, I am using an animation blueprint template and creating children of that which are then linked to the main ABP. The only thing that goes in this child ABPs is 5 animation sequences (for spring, walk, idle, ads idle, and ads walk). To make these values variable in the child BPs I need to expose as pin.

Above is my main ABP which does nothing but receive the linked ABPs

[ChenDong]

Exposed pins on anim nodes are not like UMG bindings. If the pin is driven by a plain member variable (or left unconnected and just set via the class defaults in your child template), the compiler folds it into the node’s data and there is no per-frame Blueprint evaluation at all. With Fast Path on (the little lightning icon on the node), a pin wired straight to a variable is copied as a cheap memcpy during the anim update, and that only happens for nodes that are actually updated, i.e. inside the active state(s) of the state machine. Cost only appears if you put logic between the variable and the pin (math, function calls, casts), which breaks Fast Path and runs a BP thunk every update for that node. In your setup (5 sequences assigned per child template), the sequences are effectively constant per class, so the overhead is negligible. To verify, enable “Warn About Blueprint Usage” in the ABP Class Settings, which flags any node falling off the fast path, and you can check with stat anim or Unreal Insights (Animation track) if you want hard numbers.