Open
Bug 1284368
Opened 8 years ago
Updated 2 years ago
consider aligning timers for background wndows
Categories
(Core :: DOM: Core & HTML, defect, P3)
Core
DOM: Core & HTML
Tracking
()
NEW
Tracking | Status | |
---|---|---|
firefox50 | --- | affected |
People
(Reporter: bkelly, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: power)
Attachments
(1 file)
6.76 KB,
patch
|
Details | Diff | Splinter Review |
One of the techniques for improving power efficiency is to schedule work to happen at the same time thereby reducing CPU wakeups. MS talks about doing this with timers in their background windows here: https://blogs.windows.com/msedgedev/2016/06/20/edge-battery-anniversary-update/ We already throttle our background timers to 1 second, but maybe we can try to perform some of this scheduling alignment as well. MS was able to line up timers to execute with other work throughout the OS. That is probably too ambitious for us given our cross-platform target. There are a couple easier things we could do, however, that might provide some wins: 1) Simply round background timers to fall exactly on every second or half-second. 2) Track scheduled work at the process level in our nsTimer implementation. Then round "background" timers to the nearest pre-existing scheduled timer. I have a proof-of-concept of option 1. It yields about a 20% improvement in an artificial workload: 1) Open four example.com tabs 2) Open devtools in each tab 3) In each tab execute `setInterval(_ => {console.log(Date.now()); }, 333)` with slightly different intervals. 4) Open a new about:tab 5) Measure energy with rapl I'd like to try investigating the nsTimer approach, though, because it could give us bigger wins. It would probably cost us some time/space, however. I'm pretty much just working this as a background task in my spare time. If someone else wants to run with this, please feel free to steal it.
Reporter | ||
Comment 1•8 years ago
|
||
Note, I performed more testing after comment 0 and could not reproduce a consistent battery improvement. We should continue experimenting with this, though. Our timer infrastructure has improved recently and might be better able to take advantage of this approach now.
Comment 2•8 years ago
|
||
I think before doing anything here we should wait for the results of the tracking timeout freezing project. If that works out, it should win quite a bit on multi-tab battery usage scenarios. Given that we can wake up the system for arbitrary tasks at arbitrary times, I'm not surprised that doing this just for timeouts doesn't move the needle in any meaningful way.
Reporter | ||
Comment 3•8 years ago
|
||
A first step would be to simply add a "deadline is flexible by X ms" API to nsITimer. Most other platforms have this and is what allows them to align timers. We lack it. If we had this API we could start marking timers as flexible even if we don't do anything with the data yet. For example, background setTimeout() could be flexible, GC timer deadlines could be flexible, etc.
Reporter | ||
Comment 4•8 years ago
|
||
I think we should make an nsITimer API similar to this: https://msdn.microsoft.com/en-us/library/windows/desktop/hh405404(v=vs.85).aspx With a settable tolerance delay.
Comment 5•8 years ago
|
||
We may want to split the nsITimer part into a separate bug. I still think those are two different issues.
Comment 6•8 years ago
|
||
FWIW, Chrome aligns timers to the 1 second boundary roughly as done in the proposed patch: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/scheduler/renderer/task_queue_throttler.cc?type=cs&q=TaskQueueThrottler::AlignedThrottledRunTime&l=482
Reporter | ||
Comment 7•8 years ago
|
||
(In reply to Ojan Vafai from comment #6) > FWIW, Chrome aligns timers to the 1 second boundary roughly as done in the > proposed patch: > https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/ > scheduler/renderer/task_queue_throttler.cc?type=cs&q=TaskQueueThrottler:: > AlignedThrottledRunTime&l=482 That is basically the patch I tried before. I couldn't measure any battery improvement from it.
Comment 8•7 years ago
|
||
Assuming this is P3 due to lack of recent activity. Feel free to correct me.
Priority: -- → P3
Reporter | ||
Updated•6 years ago
|
Assignee: ben → nobody
Status: ASSIGNED → NEW
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•