GeezerVison

cc @pitrou @eryksun @zooba

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

Before:

time():
- efffective resolution: 15 ms
- implementation: GetSystemTimeAsFileTime()
- resolution: 16 ms

perf_counter():
- efffective resolution: 100 ns
- implementation: QueryPerformanceCounter()
- resolution: 100 ns

monotonic():
- efffective resolution: 100 ns
- implementation: QueryPerformanceCounter()
- resolution: 100 ns

After:

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

perf_counter():
- efffective resolution: 100 ns
- implementation: QueryPerformanceCounter()
- resolution: 100 ns

monotonic():
- 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 using PCbuild\build.bat -e -p x64 command), I confirm that GetSystemTimePreciseAsFileTime() ("change") is slower than GetSystemTimeAsFileTime() ("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 new time.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.