remove 'TIMER' printing on stdout on non debug builds

[fabio]

The game prints messages like:

TIMER| InitVfs: 231.748 ms
TIMER| InitScripting: 3.26417 ms
TIMER| CONFIG_Init: 5.34321 ms

when run. Apparently these messages are not very useful (I never saw something related to them in the forums), and distract users from other possibly useful messages, so they could probably be removed from non-debug builds.

[historic_bruno]

Hmm, but wouldn't the timers be different for release (optimized) vs. debug builds? I agree most people don't care about those messages.

[fcxSanya]

If they are usable for something, then it is probably better to move them in some log files, rather than disable for release and keep for debug builds.

[jan]

I think these messages do indeed have value - I look over them every time someone posts a bug report that includes debug output. This allows checking whether someone's system is unduly strained by something that might work well on our usual computers. We would not otherwise have access to this kind of data.

However, my perspective is based on the fact that these debug messages aren't bothersome (they go into a little window in the IDE that is automatically cleared before each run). Is some other similar mechanism available on Linux? I was thinking of writing a little viewer for this debug output channel on Windows anyway because OutputDebugString is ungodly slow and DbgView (basically what I am aiming to replace) crashes periodically on Win7 x64. Maybe a cross-platform version of it would be useful?

The problem with separate software and/or a log file is that people might not know to look at them - e.g. if a performance bug was introduced that has no other visible side effects.

[Philip]

The new profiler makes these messages partially redundant - if we want to optimise startup/shutdown/etc performance, we can add PROFILE2 macros and use the external profile viewer to see how long everything took (with the benefit of being able to time nested sections and see what files it's loading etc, and the drawback of either having a more crowded display or having to write more code to postprocess the data). If we add a (possibly automatic) profile-data upload feature then we could also see how it works on other people's computers.

[jan]

That sounds great, especially the automatic upload :) In that case, we could remove these messages without any loss.