[webkit-dev] setTimeout as browser speed throttle
mjs at apple.com
Thu Oct 2 21:58:55 PDT 2008
On Oct 2, 2008, at 9:39 PM, Darin Fisher wrote:
> I am indeed interested in passive feedback from users and web
> developers. But I'm also interested in the anonymous, opt-in
> aggregate data collection that we can perform ourselves (as Linus
> mentioned). The challenge is to find a way to be confident in
> selecting a clamp value. Feedback from users seems like an
> important metric but it is not the only metric.
I think testing on already the known problem sites with different
clamp values, and hunting for more problem sites in some active way,
are probably the most valuable additional data gathering that we can do.
> I think that users often only notice high CPU usage after it has
> been occurring for a while. At that point it is frequently not well
> correlated to recent browsing activity. You might have already
> opened other tabs. Maybe it was even a background tab that started
> acting up. In a single process browser, a user just sees the
> browser process consuming CPU. In Chrome, they see a particular tab
> (or maybe a set of tabs) consuming CPU. So they can diagnose the
> problem and point fingers more easily.
Our experience is that users often do notice what site is
inadvertantly causing high CPU, because they file bug reports
mentioning the URL, and pointing out that it doesn't cause the same
problem in Firefox. Now, it might be that there are even more problems
where the user does not identify the problem site and does not file a
bug; I have no way to rule out that possibility.
> In short, our architecture makes me more willing to take risks with
> setTimeout clamping than I would be otherwise. This is a good thing
> I think because we have the opportunity to test this out and get
> more data without risking as much.
I guess I don't expect it to make a huge difference but if you would
like to test a value higher than 1ms but less than 10ms in live code
I'd certainly love to hear the results.
>> Laptops on battery power are not an issue since we wouldn't want to
>> enable high-res timers on those systems. timeBeginPeriod(1) being
>> too costly there.
> There's no such thing as timeBeginPeriod on Mac or Linux. And I
> believe the timeBeginPeriod problem is solvable on Windows (there is
> no need to have it on all the time). Overall I think it would be
> poor form if site behavior changed depending on whether I was
> plugged into a power cable.
> Yeah, I realize that this is a Windows only API.
The reason that I mention this is that on Mac and Linux systems,
there's no special power-wasting system call to "enable high-res
> I think we just disagree here. In my opinion since setTimeout
> clamping is so varied across browsers and even varies in Firefox
> depending on whether or not a flash animation is going, the
> expectation of consistent clamping has to be low. Or at least it
> has to be the case that it doesn't matter much if different browsers
> have different clamping values in practice. So I think there is
> room to do interesting things related to different power management
> states. Anyways, I'm just telling you what we are considering doing.
I'm not really talking about developer expectation here so much as the
possibility that, if indeed a lower clamp is a performance improvement
for real sites, then said sites would noticeably slow down the moment
you unplug. As a user I would find that surprising and weird.
> (I don't understand your comment about not having to have it on all
> the time. Surely if a page is asking for a fast setTimeout
> repeatedly, it would be on "all the time.")
My understanding is that timeBeinPeriod(1) is currently on all the
time in Chrome, even when no short-delay timers are currently pending,
thus leading to constant greater power consumption. But there is no
need for it to be on when there are not fast timers pending. See
WebCore/platform/win/SharedTimerWin.cpp. I think that is a technically
better approach than switching based on power management state.
Feedback welcome, though, and perhaps you will still come to a
More information about the webkit-dev