GameEvent StackTraces create a lot of garbage

[jeffcampbellmakesgames]

I used this library quite a bit during the Ludum Dare jam this past weekend and I noticed several times that the StackTrace feature of GameEvents creates quite a bit of garbage. For each game event raised, 9kb of garbage is created and 2.4ms of CPU time is consumed.

Multiply that by 100 for as many game events raised on a single frame and you get 1.2 mb of garbage and 28.84ms of cpu time consumed.

I personally haven't found the stacktrace part of this feature to be that useful (particularly when clicking the raise button in the inspector the stacktrace is me clicking that button) and it is limited to editor-only by use of preprocessor directives, but on performance sensitive platforms like VR or mobile this could very easily lead to noticeable performance hiccups that you wouldn't see in a build (inconsistent behavior).

We have a few options here:

• Remove the feature entirely which would remove the performance hits, but lose the feature. I'd be curious to see how many users are actively using the stacktrace feature.
• Modify the use of the feature to be optional out so that a developer could toggle the use of this feature if desired and others could turn it off to avoid the performance hits and confusion.
  • I would likely implement this using an additional preprocessor directive like SO_STACK_TRACE_ON and add a menu item that would utilize the PlayerSettings class to add or remove the relevant directive. If that didn't work because of the use of the AssemblyDefinition (AsmDef), we might be able to use the new version defines feature on the AsmDef to accomplish the same thing (I'm not as familiar with this, but it sounds like a custom DEFINES section for the AsmDef).

[DanielEverland]

Fixed by adding a "Debug Mode" option in the settings. Disabling this setting will also disable stack traces, and can be used elsewhere in the codebase for debug-only features.

It also displays a nifty warning in the inspector