Open Bug 1107626 Opened 10 years ago Updated 3 years ago

Evaluate aggregating timers to reduce the number of times we wake up the CPU for serving them

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

Project Flags:
Performance Impact medium

People

(Reporter: gsvelto, Unassigned)

References

Details

(Keywords: perf:resource-use)

It might be worth checking if there would be any value in aggregating timers with identical (or close enough) intervals to reduce power consumption. The rationale behind this is that on modern devices (and especially phones) taking the CPU out of standby and into an high-power state has fixed power costs. So, for example if we have two timers with the same interval, making them trigger back-to-back would allow us to save some power compared to having them trigger at separate times. This could also have performance benefits in terms of already warmed up caches. One thing worth analyzing is if how much aggregation could be done without impacting the user experience. While JS timers are not guaranteed to trigger at the exact requested time, merging two 30 minutes timers and having one of the two trigger 15 minutes later than expected might be a little too much. IIRC the Linux kernel should already do something similar in the form of event aggregation (i.e. running interrupt-handlers and such back-to-back when possible instead of waiting for them to trigger) but I'm not sure if this applies to timers as well.
For avoidance of doubt, are you talking about aggregating JS timers (i.e. setTimeout) or aggregating XPCOM timers (nsITimer)? I'm pretty sure we do the former, though maybe we could be more aggressive in coalescing them...
Flags: needinfo?(gsvelto)
(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #1) > For avoidance of doubt, are you talking about aggregating JS timers (i.e. > setTimeout) or aggregating XPCOM timers (nsITimer)? I'm pretty sure we do > the former, though maybe we could be more aggressive in coalescing them... I was thinking about JS timers. I remember noticing some time ago that the FxOS homescreen was using two setInterval() timers of 1s each and they were firing every 0.5s waking up the phone twice when once would have been enough. I didn't do extensive testing though so I might be wrong. BTW most recent OSes tend to do timer aggregation already but they're not very aggressive; they'll lump two timers together if they're going to tick ms apart from each other but not much more than that.
Flags: needinfo?(gsvelto)
We're not very good at aggregating JS timers. There have been pages which make FF slow because of too many nsITimers which are created for JS timers.

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5

This work is pretty important for mobile, and I would argue is pretty important for being competitive with respect to power consumption in general (laptops etc). I'd like to request that this bug be reconsidered. Thanks!

Flags: needinfo?(jstutte)

We should often be running many setTimeout timers during a single thread level task,
https://searchfox.org/mozilla-central/rev/58e955b8005b4845c42e874a6b9aa5b223ef0d82/dom/base/TimeoutManager.cpp#684 and onward.

This bug was filed way before any of the timeout handling changes landed.
Would be nice to get some data here what to improve.

(In reply to Aaron Klotz [:aklotz] from comment #5)

This work is pretty important for mobile, and I would argue is pretty important for being competitive with respect to power consumption in general (laptops etc). I'd like to request that this bug be reconsidered. Thanks!

(In reply to Olli Pettay [:smaug] from comment #6)

Would be nice to get some data here what to improve.

Hi Aaron, can you gather such evidence that this is still an issue?

Flags: needinfo?(jstutte) → needinfo?(aklotz)

I'll raise this at my team's weekly meeting tomorrow, though given the timing we might not be able to properly discuss it until the new year.

Flags: needinfo?(aklotz)

Adding perf triage tag – seems like a pretty reasonable battery improvement effort for fenix but "collecting a bit of data could help determine if this is high value - Even adding a log that we could read from logcat to see how often this is happening." (quote from acreskey)

Whiteboard: [qf]

The timer implementation has extensive logging built in and it can be turned on dynamically: https://searchfox.org/mozilla-central/rev/dd042f25a8da58d565d199dcfebe4f34db64863c/xpcom/threads/nsTimerImpl.cpp#46

Also switching the platform to All/All because this is most definitely not a B2G-specific thing now though it would help there too :-)

OS: Gonk (Firefox OS) → All
Hardware: ARM → All
Whiteboard: [qf] → [qf:p2:resource]
Performance Impact: --- → P2
Keywords: perf:resource-use
Whiteboard: [qf:p2:resource]
You need to log in before you can comment on or make changes to this bug.