[issue37205] time.perf_counter() is not system-wide on Windows, in disagreement with documentation
STINNER Victor
report at bugs.python.org
Mon Nov 16 10:13:02 EST 2020
STINNER Victor <vstinner at python.org> added the comment:
I close the issue, it's now fixed in master. Thanks for the bug report Ken Healy.
While Python 3.8 and 3.9 are also affected, I prefer to leave them unchanged to avoid bad surprises during a minor update (3.x.y bugfix release). If you disagree, please speak up!
The regression was introduced in Python 3.7 by:
commit bdaeb7d237462a629e6c85001317faa85f94a0c6
Author: Victor Stinner <victor.stinner at gmail.com>
Date: Mon Oct 16 08:44:31 2017 -0700
bpo-31773: _PyTime_GetPerfCounter() uses _PyTime_t (GH-3983)
* Rewrite win_perf_counter() to only use integers internally.
* Add _PyTime_MulDiv() which compute "ticks * mul / div"
in two parts (int part and remaining) to prevent integer overflow.
* Clock frequency is checked at initialization for integer overflow.
* Enhance also pymonotonic() to reduce the precision loss on macOS
(mach_absolute_time() clock).
This change was related to the implementation of the PEP 564.
If you are curious about this work, I wrote two articles:
* https://vstinner.github.io/python37-pep-564-nanoseconds.html
* https://vstinner.github.io/python37-perf-counter-nanoseconds.html
* https://vstinner.github.io/pytime.html
----------
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37205>
_______________________________________
More information about the Python-bugs-list
mailing list