This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Use CLOCK_MONOTONIC_COARSE in GetTickCount64#2293
Merged
stephentoub merged 1 commit intodotnet:masterfrom Dec 10, 2015
Merged
Conversation
Today, GetTickCount64 is implemented to use clock_gettime with CLOCK_MONOTONIC if it's available. This provides for high-resolution, however it trades off that accuracy for some efficiency. This commit changes it to prefer CLOCK_MONOTONIC_COARSE if it's available (QueryPerformanceCounter still uses CLOCK_MONOTONIC). GetTickCount is typically used for coarse timings, e.g. used in a loop to determine whether more than 10 seconds have passed, and can have lower resolution in exchange for higher efficiency. For Windows, the MSDN docs explicitly state that it's likely to have no better than 10-15 millisecond resolution. Using CLOCK_MONOTONIC_COARSE instead of CLOCK_MONOTIC maps better to this notion, and improves Environment.TickCount throughput on my machine by ~20x. At the same time, on my machine it still provides well better than 10-15ms resolution, closer to ~4ms.
Member
|
LGTM, thanks for looking into that! |
Member
Author
|
Thanks, Jan. |
stephentoub
added a commit
that referenced
this pull request
Dec 10, 2015
Use CLOCK_MONOTONIC_COARSE in GetTickCount64
picenka21
pushed a commit
to picenka21/runtime
that referenced
this pull request
Feb 18, 2022
Use CLOCK_MONOTONIC_COARSE in GetTickCount64 Commit migrated from dotnet/coreclr@2aa39ea
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Today, GetTickCount64 is implemented to use clock_gettime with CLOCK_MONOTONIC if it's available. This provides for high-resolution, however it trades off that precision for some efficiency.
This commit changes it to prefer CLOCK_MONOTONIC_COARSE if it's available (QueryPerformanceCounter still uses CLOCK_MONOTONIC). GetTickCount is typically used for coarse timings, e.g. used in a loop to determine whether more than 10 seconds have passed, and can have lower resolution in exchange for higher efficiency. For Windows, the MSDN docs explicitly state that it's likely to have no better than 10-15 millisecond resolution. Using CLOCK_MONOTONIC_COARSE instead of CLOCK_MONOTIC maps better to this notion, and improves Environment.TickCount throughput on my machine by ~20x. At the same time, on my machine it still provides well better than 10-15ms resolution, closer to ~4ms.
After this change, Environment.TickCount is still ~2x slower on my Linux machine than on my Windows machine (though with better precision), but my Linux machine is a VM, and I tested a bunch of different time mechanisms and I think this is the best we can do given the various constraints.
Fixes https://github.com/dotnet/coreclr/issues/2257
cc: @janvorli, @ianhays