Bug 153042 - Windows system timer resolution needlessly cranked up when nextFireTime is in the past
Summary: Windows system timer resolution needlessly cranked up when nextFireTime is in...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: WebKit Nightly Build
Hardware: PC Windows 7
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-01-12 15:47 PST by John N. Lehner
Modified: 2016-01-13 13:43 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John N. Lehner 2016-01-12 15:47:26 PST
In http://trac.webkit.org/browser/trunk/Source/WebCore/platform/win/MainThreadSharedTimerWin.cpp

if MainThreadSharedTimer::setFireInterval() is called with an interval of 0, as will happen when ThreadTimers::updateSharedTimer() executes

m_sharedTimer->setFireInterval(std::max(nextFireTime - currentMonotonicTime, 0.0));

with nextFireTime in the past, then the following executes:

138    if (Settings::shouldUseHighResolutionTimers()) {
139	        if (interval < highResolutionThresholdMsec) {
140	            if (!highResTimerActive) {
141	                highResTimerActive = true;
142	                timeBeginPeriod(timerResolution);
143	            }

highResolutionThresholdMsec is 16, so 0 < 16 and we call timeBeginPeriod(1) which stays in effect ~1/3 of a second.  This increases power consumption needlessly.

We should only increase the system timer resolution if we're going to actually proceed to the CreateTimerQueueTimer() call; if we're going to PostMessage() immediately no resolution increase is necessary.
Comment 1 Brent Fulgham 2016-01-13 13:43:29 PST
Nice catch! We'll try to allocate some time to this soon.