Minor removal of evaluating + on strings in logging functions.

[chuggafan]

This is to partially address #1114
upstream/master: 20:7.09
This patch applied: 0:18:41.26
Patch + my work in #1112 after a 2nd build: 0:17:49.36
~1.2 minutes shaved
Turns out doing a bunch of logic that doesn't get used is wasteful.
I also ran multiple compile sets before this, so if there were any files in the disk-cache it would affect both.
This may be within variance(?) but at the minimum this does clear out a ton of cases where my logging adds unnecessary time.
In theory, if I switch to a set of macro calls that do an inline check before the call I may save some time with all of those logging calls by just not doing a call instruction callout whatsoever, but that's an additional effort thing there.
It does appear that my attempt to keep the number of occparses under control is still failing(? this may be because of task manager not clearing them out as they come up, I'd need a better way to verify this.... a global semaphore acting as a counter?)
I did cherry-pick this from my master branch in #1112 , so I can drop this and just treat my main branch as the main "run through all the optimizations" branch.

[GitMensch]

If that already brings in that performance - why not changing the logging to use macros;

• check the logger's verbosity with a new function DoesLog(verbosity) before doing the actual string setup + call completely - or expose the verbosity directly so no function call needed at all
• include __func__ in the args - so less different coding
• optionally: disable at compile time for "performance-release" builds

[LADSoft]

so thank you for looking at this so quickly! yeah ill tell you i wasn't very precise on the timing so this will probably take care of most of the issue :).

[chuggafan]

If that already brings in that performance - why not changing the logging to use macros;

• check the logger's verbosity with a new function DoesLog(verbosity) before doing the actual string setup + call completely - or expose the verbosity directly so no function call needed at all
• include __func__ in the args - so less different coding
• optionally: disable at compile time for "performance-release" builds

I would do this, but at this time I'm not quite sure if it would actually be a speedup to hoist the conditional out of the call whatsoever.
Part of why I added the logging was to be able to enable it during release builds, a-la how gnu make allows you to just dump tons and tons of logging information.
I'd probably have to sit down and actually think about how logging should work and speedily past this point which is why I just went for the easy slowdown areas.

[GitMensch]

We can have the disabling part as something commonly not done in our release builds while still providing that option (which we may use for CI environments if not needed temporarily).
The conditional outside of the function call will definitely help, especially when you use the logging in many places:

• simple conditional check removes the need to create any String / StringView object if not logged [that would also "hide" the costs when logging is enabled - but you've tackled that in this PR - so the change is good in any case]
• if the active log level is exposed: no function call at all, otherwise a simple one passing an int, returning a bool - instead of a function taking multiple arguments for the actual log call

[LADSoft]

are you ready for me to merge this?

[chuggafan]

In terms of the basics, this PR is "done".
Everything else is additional profiling and checking from @GitMensch 's suggestions.

I agree on the point that I need to go out and check the difference in speed between a decent logging loop where we hoist the check out of the hot path, but I'm not sure on how that will affect performance at this time.
I think I got the low-level fruit from my changes, there's definitely more that can be done to avoid what happens when we get vararg functions....