Macos Optimization

[Tillsunset]

clock_gettime_nsec_np is an optimization of clock_gettime, roughly 90% time needed from some testing. It is specific to macOS though.

CLOCK_MONOTONIC_RAW_APPROX is another potential optimization for macOS, roughly 50% time needed compared to CLOCK_MONOTONIC_RAW. But typically only guarantees 1 millisecond accuracy. Its potential usage and overall speedup is extremely debatable. I could see it potentially being used in GetTickCount() and tick_cached().

clock_getres also always returns 1 nanosecond, I'm not sure if that is the intended purpose when used in HighResolutionTimer::getFrequency(). Feedback needed

[Exzap]

Thanks for looking into this. I think some additional context and history on our timer functions would help.

First, we consider all time sources except for HighResolutionTimer to be deprecated. Using std::chrono::steady_clock for code where performance isn't a high priority is ok, but personally I would discourage it's use in critical code because it can be difficult to predict the latency and resolution of the various implementations.

Before HighResolutionTimer was introduced, we had tick_cached and now_cached as a workaround for Microsoft's slow implementation of std::chrono::steady_clock::now() (and high_resolution_clock). As far as I know this has been resolved by now but other implementations might still be slow.

Later, we added PPCTimer as a timer source specifically for CPU emulation, where we need maximum performance and resolution, with a small amount of drift acceptable. This lowered the importance of tick_cached and now_cached to be as fast as possible, since they were no longer frequently called on the hot path.

Pretty recently we then introduced HighResolutionTimer with the goal of providing a unified, simple, high-performance, high-accuracy, and high-resolution interface for our timing needs. In the long term, the goal is to replace all other timers with HighResolutionTimer.

Anyway, your PR looks good. As mentioned there isn't really a need to hyper optimize tick_cached/now_cached anymore so using something like CLOCK_MONOTONIC_RAW_APPROX would be overkill.

clock_getres also always returns 1 nanosecond, I'm not sure if that is the intended purpose when used in HighResolutionTimer::getFrequency(). Feedback needed

That matches the man page and expected behavior. The frequency is 1ns and clock_gettime_nsec_np returns the time in nanoseconds. On Windows the frequency is dynamic, but in theory for macOS we could leverage the fact that it's fixed and define m_freq as a compile-time constant. The performance gain would likely be pretty insignificant tho.