[REG-2191] Speedup game action analysis

[nAmKcAz]

• Dramatically shortens the time required to analyze game actions

  • Loads scenes in preview instead of actually modifying the loaded scenes in the editor (this is both for performance and functional to not mess with the user's editor state)
  • Caches type field/property resolutions
  • Reduces 'new' object allocations/gc and prefers re-use
  • Fixes various code style warnings in the analysis file
  • Optimizes the multi loop code analyzer that always ran at least 2 passes to only run >1 passes when necessary
    • Confirmed with Beyond Compare text on a large customer project that before and after results are equivalent
  • Uses multithreading to run resource analysis and code analysis in parallel (also parallelizes parts of code analysis itself)
    • Still provides detailed status/cumulative-progress updates during the multithreaded operations

• I was honestly hoping to get this down to single digit seconds for ALL games so that we could include it as a compile time trigger automatically. Sadly... that's just not possible for large games as we are limited by Unity's Main Thread access restrictions when doing game resource analysis.

• Bossroom Before (~13 sec)
  

• Bossroom After (<4 sec)
  

• Large Customer Project before (~120 sec)
  

• Large Customer Project after (<40 sec)
  

---

Find the pull request instructions here

Every reviewer and the owner of the PR should consider these points in their request (feel free to copy this checklist so you can fill it out yourself in the overall PR comment)

• The code is extensible and backward compatible
• New public interfaces are extensible and open to backward compatibility in the future
• If preparing to remove a field in the future (i.e. this PR removes an argument), the argument stays but is no longer functional, and attaches a deprecation warning. A linear task is also created to track this deletion task.
• Non-critical or potentially modifiable arguments are optional
• Breaking changes and the approach to handling them have been verified with the team (in the Linear task, design doc, or PR itself)
• The code is easy to read
• Unit tests are added for expected and edge cases
• Integration tests are added for expected and edge cases
• Functions and classes are documented
• Migrations for both up and down operations are completed
• A documentation PR is created and being reviewed for anything in this PR that requires knowledge to use
• Implications on other dependent code (i.e. sample games and sample bots) is considered, mentioned, and properly handled
• Style changes and other non-blocking changes are marked as non-blocking from reviewers

[abeizer]

I was honestly hoping to get this down to single digit seconds for ALL games

This improvement is huge though! Very impressed by the time save

[addisonbgross]

I'm sure this could use at least one more review from someone other than I, to give these changes a thorough check, but overall this is excellent

[addisonbgross]

most satisfying change of this PR

Edit: I see you change this a few times 👏🏻

[addisonbgross]

would await Task.Yield() have the same effect? Just curious

[nAmKcAz]

it doesn't have exactly the same effect, but similar intent

await Task.Yield() will absolutely ensure you get a new synchronization context for the following lines (force them to run async)

await Task.completedTask is quite a bit faster to execute, but does not strictly guarantee a new context.. however, since I spawned an async task, i really just needed something to make that async code 'valid' (have an await)... based on how the code evolved I could even remove 1 or 2 of these and it work the same, but I left them in to ensure that future updates/modifications wouldn't un-expectedly change the threading behavior

[addisonbgross]

Good to learn, thanks