We were running the profiler the other day trying to figure out some slowdown, when we came across this!
We recently updated from like 2.14.4 to 2.20; and perhaps the issue may have sprung up in the meantime? Any ideas as to what could be causing the spike?
Edit:
Here's the full stack trace for the spike:
It looks like it uses reflection 20k(!) times after we invoke the damage.
I'll look into the reflection call. Generally, when your damage dealer uses a battle event it'll have some memory overhead, as it has to load the battle event - and in your case also the Makinom schematic.
Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found. If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
The reflection call isn't something to worry about - while it looks like a lot, this isn't having much impact and is only done once to find the class for the name you defined. If this happens every time this class is used via reflection, it's probably not finding it and the nodes shouldn't be doing anything (e.g. in that case enabling the component). If the class is in a namespace, you should be able to shorten this by also defining the namespace (e.g. MyNamespace.MyClass instead of only MyClass).
How high is the impact without using Deep Profile? Since this adds a huge overhead, often blowing up the numbers by over 100 times, it's hard to tell if this is out of the ordinary or not ...
Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found. If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Hmm, even without using Deep Profile; it still seems to generate a .9MB of garbage at some point on DamageDealer. Both the battle event and the Makinom schematic it calls are pretty lightweight and tiny. The first image was just using the standard profiler, I believe. We're fairly sure it didn't happen before the update...
I'm pretty sure the first image also uses deep profile, otherwise you wouldn't be able to see the calls for individual nodes in the event :)
Anyway, the size allocated by the garbage collector for starting an event (and schematic) depends on the event/schematic and the resources it uses. A large event with a lot of nodes could have less GC allocation than a small event that uses a lot of resources (e.g. prefabs, audio clips).
Please consider rating/reviewing my products on the Asset Store (hopefully positively), as that helps tremendously with getting found. If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
Generally, when your damage dealer uses a battle event it'll have some memory overhead, as it has to load the battle event - and in your case also the Makinom schematic.
If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
If the class is in a namespace, you should be able to shorten this by also defining the namespace (e.g. MyNamespace.MyClass instead of only MyClass).
How high is the impact without using Deep Profile? Since this adds a huge overhead, often blowing up the numbers by over 100 times, it's hard to tell if this is out of the ordinary or not ...
If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
---------------------------------------
Personal Twitter: https://twitter.com/AMO_Crate
I make RFI! https://twitter.com/NootboxGames
Anyway, the size allocated by the garbage collector for starting an event (and schematic) depends on the event/schematic and the resources it uses. A large event with a lot of nodes could have less GC allocation than a small event that uses a lot of resources (e.g. prefabs, audio clips).
If you're enjoying my products, updates and support, please consider supporting me on patreon.com!
---------------------------------------
Personal Twitter: https://twitter.com/AMO_Crate
I make RFI! https://twitter.com/NootboxGames