About continuous GC allocation

[zhuchunParticipant]

Hi, I’m using Profiler and Performance Testing API to benchmark NodeCanvas. A found that surprised me is that each time NC invoke a reflected method or set a bound field, it generates garbage, about 30~38m per million calls/ticks. Is that normal?

I thought that was an initialize cost, as the website said “…zero allocations after initialization”, but Profiler showed me that the garbage was generated in every frame my script runs

[attachment file=”gc-1.png”]

[GavalakisKeymaster]

Hello there,

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!

[zhuchunParticipant]

Thanks for your insight, that explained a lot!

Does it mean that if my project is targeting for cross-platforms, it’d better use the AOT version of those actions if they have, in case of JIT compilation failure?

[GavalakisKeymaster]

Hello again,

Yes, if you are targeting cross-platform, please do not use the reflection tasks categorized under “Faster Versions (Desktop Platforms Only”, since they only work in JIT platforms (non-il2cpp desktop). Everything outside this category, will work in AOT platforms.

Thanks!

[Author]

Posts