[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