Indeed, garbage in regards to reflection can not be fully avoided. In regards to data bound variables, binding variables to properties (instead of fields) is far more optimized, so you may want to prefer binding to properties instead of fields if possible for you. In regards to actions/conditions that utilize reflection, if you are targeting JIT platforms (meaning mostly desktop), the reflection tasks categorized under the “Faster Versions (Desktop Platforms Only)” are also far more optimized than the normal (non-fast) reflection tasks. That is because such optimizations can actually be done in JIT platforms whereas not possible in AOT platforms.
The zero allocation after initialization do not really include what the actions/conditions do since that can be anything (even user made) which may or may not create garbage. Thus this statement really refer to the main execution loop of the graph.
Some features however will create garbage where it is not possible to optimize. For example the “AutoConvert” feature (where you can link a variable to a parameter of a different type, will create garbage (depending on the type conversion), since for example converting value types (structs) is not possible without creating garbage.
Thus once again, please prefer to use property bound variable instead of field bound ones, as well as opt to use the “Faster Version” of reflection tasks if you are targeting JIT platforms. If you are targeting AOT platforms, please prefer to create custom tasks instead of using reflection-based tasks in critical paths (parts of the graph where you expect to be called per-frame by a lot of graphs simultanously).
Please let me know if the above helps and works for you.
Thank you!
Join us on Discord: https://discord.gg/97q2Rjh
Login
Register
By registering on this website you agree to our Privacy Policy.
