On Wed, Apr 28, 2021 at 9:35 PM Christian Franke <christian.fra...@t-online.de> wrote: > > Liu Hao wrote: > > 在 4/27/21 2:00 AM, Christian Franke 写道: > >> > >> Which complexity do you mean - the extra cost of the system call or > >> the extra 15 lines of code? > >> > > > > It's actually both. > > > > Wall clocks are not meant to be steady, because they are free to jump > > back and forth due to NTP synchronization, and arithmetic operations > > aren't predicable either due to leap seconds. > > That's all correct. But there are several use cases where a higher than > this ~15.6ms (1/64s) resolution is needed and where occasional clock > jumps are acceptable - for example debug logs. > > If there were no use cases, the evolution > time() -> ftime(...) -> gettimeofday(...) -> > clock_gettime(CLOCK_REALTIME,...) > would possibly never have happened :-) > > BTW.1: Hack: > Do this once in the program > #ifdef _WIN32 > timeBeginPeriod(1);
https://docs.microsoft.com/fr-fr/windows/win32/api/timeapi/nf-timeapi-timebeginperiod?redirectedfrom=MSDN "Setting a higher resolution can improve the accuracy of time-out intervals in wait functions. However, it can also reduce overall system performance, because the thread scheduler switches tasks more often. High resolutions can also prevent the CPU power management system from entering power-saving modes. " also, just for more information about this discussion: https://devblogs.microsoft.com/oldnewthing/20170921-00/?p=97057 Vincent Torri _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
