Skip to content

time.monotonic() should use a different clock source on Windows #88494

Description

@lunixbochs
mannequin
BPO 44328
Nosy @pfmoore, @abalkin, @vstinner, @tjguk, @zware, @eryksun, @zooba, @pganssle, @lunixbochs

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-06-06.22:05:07.766>
labels = ['3.11', 'library', 'OS-windows', 'performance']
title = 'time.monotonic() should use a different clock source on Windows'
updated_at = <Date 2021-06-14.21:10:46.833>
user = 'https://github.com/lunixbochs'

bugs.python.org fields:

activity = <Date 2021-06-14.21:10:46.833>
actor = 'eryksun'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)', 'Windows']
creation = <Date 2021-06-06.22:05:07.766>
creator = 'lunixbochs2'
dependencies = []
files = []
hgrepos = []
issue_num = 44328
keywords = []
message_count = 12.0
messages = ['395221', '395238', '395490', '395493', '395681', '395683', '395719', '395769', '395771', '395782', '395784', '395849']
nosy_count = 9.0
nosy_names = ['paul.moore', 'belopolsky', 'vstinner', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'p-ganssle', 'lunixbochs2']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue44328'
versions = ['Python 3.11']

Linked PRs

Activity

  1. lunixbochs commented on Jun 6, 2021

    lunixbochsmannequin
    MannequinAuthor

    Related to https://bugs.python.org/issue41299#msg395220

    Presumably time.monotonic() on Windows historically used GetTickCount64() because QueryPerformanceCounter() could fail. However, that hasn't been the case since Windows XP: https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

    On systems that run Windows XP or later, the function will always succeed and will thus never return zero

    I've run into issues with this when porting python-based applications to Windows. On other platforms, time.monotonic() was a decent precision so I used it. When I ported to Windows, I had to replace all of my time.monotonic() calls with time.perf_counter(). I would pretty much never knowingly call time.monotonic() if I knew ahead of time it could be quantized to 16ms.

    My opinion is that the GetTickCount64() monotonic time code in CPython should be removed entirely and only the QueryPerformanceCounter() path should be used.

    I also think some of the failure checks could be removed from QueryPerformanceCounter() / QueryPerformanceFrequency(), as they're documented to never fail in modern Windows and CPython has been dropping support for older versions of Windows, but that's less of a firm opinion.

  2. added
    3.11only security fixes
    stdlibStandard Library Python modules in the Lib/ directory
    performancePerformance or resource usage
    on Jun 6, 2021
  3. 28 remaining items

  4. added 2 commits that reference this issue on Mar 14, 2024
  5. vstinner commented on Mar 14, 2024

    @vstinner
    Member

    I created #116781 to use QueryPerformanceCounter() for time.monotonic().

  6. vstinner commented on Mar 14, 2024

    @vstinner
    Member

    See also issue gh-115637.

  7. added 4 commits that reference this issue on Mar 14, 2024
  8. vstinner commented on Mar 15, 2024

    @vstinner
    Member

    time.monotonic() now uses QueryPerformanceCounter() (commit) and has a resolution lower than 1 us. I measured 100 ns (10 MHz) on my Windows 11 VM, whereas before it was 15.6 ms (64 Hz): the updated clock resolution is 156,000x better :-)

    Thanks everybody for looking into this issue and providing very useful technical details about these clocks.

    Follow-up: see issue gh-63207 to use GetSystemTimePreciseAsFileTime() for time.time().

  9. added a commit that references this issue on Mar 20, 2024
  10. added a commit that references this issue on Mar 25, 2024
  11. added a commit that references this issue on Apr 17, 2024
  12. added a commit that references this issue on Apr 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.12only security fixesOS-windowsperformancePerformance or resource usagestdlibStandard Library Python modules in the Lib/ directory

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions