This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients vstinner
Date 2017-10-12.14:14:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
In-reply-to
Content
The commit a997c7b434631f51e00191acea2ba6097691e859 of bpo-31415 moved the implementation of time.perf_counter() from Modules/timemodule.c to Python/pytime.c. The change not only moved the code, but also changed the internal type storing time from floatting point number (C double) to integer number (_PyTyime_t = int64_t).

The drawback of this change is that time.perf_counter() now converts QueryPerformanceCounter() / QueryPerformanceFrequency() double into a _PyTime_t (integer) and then back to double. Two useless conversions required by the _PyTime_t format used in Python/pytime.c. These conversions introduced a loss of precision.

Try attached round.py script which implements the double <=> _PyTime_t conversions and checks to check for precision loss. The script shows that we loose precision even with a single second for QueryPerformanceFrequency() == 3579545.

It seems like QueryPerformanceFrequency() now returns 10 ** 7 (10_000_000, resolution of 100 ns) on Windows 8 and newer, but returns 3,579,545 (3.6 MHz, resolution of 279 ns) on Windows 7. It depends maybe on the hardware clock, I don't know. Anyway, whenever possible, we should avoid precision loss of a clock.
History
Date User Action Args
2017-10-12 14:14:14vstinnersetrecipients: + vstinner
2017-10-12 14:14:14vstinnersetmessageid: <1507817654.69.0.213398074469.issue31773@psf.upfronthosting.co.za>
2017-10-12 14:14:14vstinnerlinkissue31773 messages
2017-10-12 14:14:14vstinnercreate