If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
3 years ago
2 years ago

People

(Reporter: gsvelto, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
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)
(Reporter)

Comment 2

3 years ago
(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)

Comment 3

3 years ago
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.
You need to log in before you can comment on or make changes to this bug.