cc@pitrou@eryksun@zooba

Clock resolution measured by the script:#116781 (comment)

Before:

time():- efffective resolution: 15 ms- implementation: GetSystemTimeAsFileTime()- resolution: 16 msperf_counter():- efffective resolution: 100 ns- implementation: QueryPerformanceCounter()- resolution: 100 nsmonotonic():- efffective resolution: 100 ns- implementation: QueryPerformanceCounter()- resolution: 100 ns

After:

time():- efffective resolution: 238 ns- implementation: GetSystemTimePreciseAsFileTime()- resolution: 100 nsperf_counter():- efffective resolution: 100 ns- implementation: QueryPerformanceCounter()- resolution: 100 nsmonotonic():- efffective resolution: 100 ns- implementation: QueryPerformanceCounter()- resolution: 100 ns

time.time() resolution is way better! 238 ns instead of 15.6 ms, it's around 65 500x more accurate!

On a release build (build usingPCbuild\build.bat -e -p x64 command), I confirm thatGetSystemTimePreciseAsFileTime() ("change") is slower thanGetSystemTimeAsFileTime() ("ref"):

vstinner@WIN C:\victor\python\main>env\Scripts\python -m pyperf compare_to ref.json change.json                                           Mean +- std dev: [ref] 35.8 ns +- 0.8 ns -> [change] 52.9 ns +- 2.2 ns: 1.48x slower

Well, more and more operating have two clocks: one slow but accurate, and one fast but less accurate. Example on Linux:

• CLOCK_REALTIME
• CLOCK_REALTIME_COARSE: A faster but less precise version of CLOCK_REALTIME

Python uses CLOCK_REALTIME for time.time(), the most precise one. So it's consistent to use the most accurate clock for time.time() on Windows as well.

If tomorrow, performance becomes an issue, we can add a newtime.time_coarse() function which would use CLOCK_REALTIME_COARSE on Linux, and GetSystemTimeAsFileTime() on Windows.

time.time() resolution is way better! 238 ns instead of 15.6 ms, it's around 65 500x more accurate!

Impressive! Finally Windows will be as good as other platforms here.