954146a5cf
It was already always high-resolution on POSIX but was never high resolution on Windows. Windows does support low latency high-resolution timers for the majority of our user base. TimeTicks::HighResolutionNow() was only explicitly requested in testing frameworks. As such I left the call in place but made it DCHECK that it's running on a Windows machine on which high-resolution clocks are used. This confirms that none of our test fleet has regressed with this change (the previous HighResolutionNow() used to be slightly more aggressive and also do it in a few configurations where we now fallback to low-resolution now). This implementation was copied as-is (modulo minor v8 API compatibility tweaks). These implementations were the same in the past but had diverged when, sadly, the same bug was fixed separately years apart, in Chromium and V8: chromium: https://codereview.chromium.org/1284053004 + https://codereview.chromium.org/2393953003 v8: https://codereview.chromium.org/1304873011 This is a prerequisite to add metrics around parallel task execution (low-resolution clocks are useless at that level, but we also don't want to incur high-latency clocks on machines that can't afford it cheaply). Bug: chromium:807606 Change-Id: Id18e7be895d8431ebd0e565a1bdf358fe7838489 Reviewed-on: https://chromium-review.googlesource.com/897485 Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#51027} |
||
|---|---|---|
| .. | ||
| condition-variable-unittest.cc | ||
| mutex-unittest.cc | ||
| platform-unittest.cc | ||
| semaphore-unittest.cc | ||
| time-unittest.cc | ||