We should run timers for out-of-view frames at a lower frequency (e.g., 1 Hz) to reduce power consumption and the performance overhead for this work which is not likely to produce useful results for the user anyway.
For power reductions we should consider not only reducing the frequency but also aligning the wakeups. If five background tabs each have five timed events then even if we throttle each event to 1 Hz we will still be waking up the CPU twenty five times per second. From a power point of view it is much more efficient to wake up the CPU once to process all 25 events.
Or, at least, it *might* be more power efficient. Reality tends to be messy, and synchronizing the timers may have unintended consequences while saving little or no power. But it's worth investigating as part of throttling timers for out-of-view frames.
#4: Actually I've got a question related to that. In Safari timers in each background process are aligned to 1 Hz, but each process uses a random phase offset. According to the commit messages this was done to avoid a thundering herd problem. I'm wondering if that is actually better than just ticking all the timers at once to race to idle.
I would guess that the best option is to issue the timers together, but one at a time - one after another. That avoids the thundering herd (only one executes at a time) but also avoids waking up the CPU throughout the second.
There may be practical considerations that make this work poorly, but it seems worthwhile trying?
The thundering herd problem is particularly acute on laptops when they wake up from standby, and it is particularly bad if many of the long-sleeping processes all try to do disk I/O at the same time, right at the moment when the user is trying to do something. In the browser case it should be much less severe because:
a) There's only one second worth of deferred work, rather than hours or days
b) There shouldn't be much disk I/O
c) The tasks aren't synchronized with when the user is trying to get something done.
Agreed that running timers as a synchronized sequence seems like the best option. I've been trying to come up with a way to do that reliably across processes, but it seems tricky especially since the timer tick in any given process might take arbitrarily long (including forever).
Maybe there's some OS-level, cgroups-like construct which could be used to lump all the background renderers together and restrict them to a low number of cores?
I was trying to find this on the perf waterfall but it doesn't seem to show up:
https://chromeperf.appspot.com/report?sid=62377080bed0bdd86b96d904f8cc7d68a1697e7d94266629b824dff51c88934f
I did a local spot check on some sites (desktop):
- The Verge: 214 tasks/s before, 123 tasks/s with cross-origin throttling and 114 tasks/s with same-origin throttling. CPU time drops from 450ms/s to 269ms/s. Looks like things are working here.
- Forbes: 223 tasks/s before, 269 tasks/s with cross-origin throttling, 232 tasks/s with same-origin throttling. Looks like this site can't be helped. Most tasks come from the top-level frame.
- LA times: 186 tasks/s before, 211 tasks/s with cross-origin throttling, 206 tasks/s with same-origin throttling. CPU time goes from 880ms to 718ms with cross-origin. Most tasks come from the top-level frame or visible child frames.
I didn't use a recorded page set for this so don't trust these numbers too much. I think it's safe to say that the effectiveness here is very site-dependent. Let's see what the data from UMA says.
I'll still grab a couple of traces on Android.
Looks like it's next to impossible to get a trace out of power.tough_ad_cases because of Telemetry changes, but I did find out that the overall number of timer fires is basically unaffected by visibility-based throttling on androidcentral.com. I think we'll need to come up with a more aggressive intervention if we want to improve sites like that.
Hmm, that is surprising :( I tested the new version specifically on Gmail to make sure pop-ups work. Maybe there's still something different on Mac.
Let me pull out the patch again for now.
Comment 1 by skyos...@chromium.org
, Jun 6 2016