1284368 - consider aligning timers for background wndows

Status: NEW

(Core :: DOM: Core & HTML, defect, P3)

Description

[Ben Kelly [:bkelly, not reviewing]]

Attachment: align_timers.patch

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.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

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

[(no longer active)]

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.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

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.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

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

[(no longer active)]

We may want to split the nsITimer part into a separate bug.  I still think those are two different issues.

Comment 6

[Ojan Vafai]

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

Comment 7

[Ben Kelly [:bkelly, not reviewing]]

(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

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Assuming this is P3 due to lack of recent activity. Feel free to correct me.