Optimize tracing terminal in sys.

[Redar13]

Does this PR close any issues? If so, link them below.

N/A

Briefly describe the issue(s) fixed.

Makes tracing terminal faster by removing some of the freezes.

[lemz1]

wait, how does this make it faster?
wouldn't using mutexes, make it technically slower, since you lock the threads, until the mutex is released?

also im pretty sure the internal printing functions already have a mutex

[EliteMasterEric]

I now have the tools to get objective data for this!

I performed the following test code, then filtered the statistics such that I was timing just the trace() call.

  function debug_testTraces():Void
  {
    for (i in 0...10000)
    {
      trace('test $i');
    }
  }

Results before this PR:

We see a cumulative time of 423.6ms with a mean of 42.36us and a max of 5.22ms.

Results after this PR:

We see a cumulative time of 478.18ms with a mean of 47.82us and a max of 4.14ms.

We also have this time distribution for debug_testTraces as a whole which I forgot to grab for the first test.

Conclusion

Reading the code itself, I'm not 100% sure what wrapping the trace call in a mutex would do here. Maybe you misunderstood how multi-threading works? Locking a mutex does NOT create a new thread to do work in, it's for managing work done by threads!

I'm not 100% certain what makes each individual call to trace() take the time it does (probably something related to the lower level system) but overall I found this PR had a slightly negative but overall negligible impact on performance, rather than the positive one this claims to have.

Feel free to reply if you have any objections but for now I will reject this PR.