This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Use CLOCK_MONOTONIC_COARSE in GetTickCount64 #2293
Merged
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