1393744 - Investigate using native timers for/instead of TimerThread

Status: NEW

(Core :: XPCOM, enhancement, P2)

Description

[Florian Bender]

+++ This bug was initially created as a clone of Bug #1325254 +++

(In reply to Ben Kelly [:bkelly] from Bug 1325254 comment #1)
> As a side project I'd like to investigate optimizing TimerThread a bit. [...] 
> 
> Also, timers have been shown in general to effect battery performance.  
> Burning extra CPU cycles in timer overhead does not help us in battery 
> showdowns with other browsers.  It would be nice to be more efficient here.

(In reply to Ben Kelly [:bkelly] from Bug 1325254 comment #12)
> I still think native timers might be worth it.  Its not clear how well
> gecko-level timer solutions work with mobile devices that enter low-power
> modes.  The native timers are probably more battery efficient and also more
> accurate when waking from low-power mode.  That's just a theory, though.

I think this is worth investigating if this solution would help in any way. Since Apple is often comparing battery usage for their browser selling points, it may be worthwhile to implement a proof of concept for macOS and then see if this improves things.

Comment 1

[Nathan Froyd [:froydnj]]

(In reply to Florian Bender from comment #0)
> I think this is worth investigating if this solution would help in any way.
> Since Apple is often comparing battery usage for their browser selling
> points, it may be worthwhile to implement a proof of concept for macOS and
> then see if this improves things.

I know Windows has a timer API...does Mac?  It looks like glib has some kind of timer API, so maybe that would take care of concerns on Linux.  No idea on Android, but I'm suspecting we might have to roll our own there.

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

I think if we do this we would need to maintain nsTimer thread implementation as well for non tier 1 platforms.  We could also implement it incrementally across platforms as well.

To really get any battery improvement we would need to change our nsITimer API to allow code to specify "fuzzy" deadline ranges.  A lot of timer battery improvements come from letting the OS shift deadlines across the entire system to align and minimize CPU wakeups.  Right now we don't expose an API that lets code opt-in to this kind of optimization.

And Android does APIs that are designed to be battery efficient for this kind of this:

https://developer.android.com/reference/android/app/AlarmManager.html#setWindow(int,%20long,%20long,%20android.app.PendingIntent)

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Also, I hesitate to put much effort into this without first standing up some kind of battery monitoring automation tests.  Without that we won't know if changes are effective or not.

Comment 4

[Nathan Froyd [:froydnj]]

(In reply to Ben Kelly [:bkelly] from comment #3)
> Also, I hesitate to put much effort into this without first standing up some
> kind of battery monitoring automation tests.  Without that we won't know if
> changes are effective or not.

And whether those tests actually point to timer management being some sort of power culprit, rather than just "we fire way too many timers".

Comment 5

[Ben Kelly [:bkelly, not reviewing]]

(In reply to Nathan Froyd [:froydnj] from comment #4)
> And whether those tests actually point to timer management being some sort
> of power culprit, rather than just "we fire way too many timers".

Reducing timers helps, sure.  Less work is always better.  I think we've gotten somewhat better from the content setTimeout() case here.  Probably a lot more work for stuff like GC, though.


Still, aligning timers across the OS can still improve battery for the same number of timers.  Similar amount of work, but creates gaps of time where the CPU can enter low power mode.

Comment 6

[Daniel Holbert [:dholbert]]

RE [qf] nomination -- is there an anticipated speedup here, along with the battery-life win?  (Battery performance improvements are great, but not really a criteria for the QF project.)

Comment 7

[Florian Bender]

Daniel, there could very well be a perceived performance gain since the OS can be smarter at scheduling things with respect to the overall system load. Would this make you reconsider this bug for QF?

Comment 8

[Daniel Holbert [:dholbert]]

I don't claim to understand much about system timers, but it doesn't sound like perf speedup is the primary goal or an especially-guaranteed outcome here (and that's fine! it just means this isn't QF material. QF is meant to be a narrowly-scoped effort.)

The OS being "smarter about scheduling things" is all well and good, but it doesn't sound like it's guaranteed to provide a measurable improvement in pageload/render time -- in fact, it sounds like it might even delay some of our callbacks a bit (so it might even trigger a marginal perf loss), though probably not in an especially noticeable way.

Again, this is all fine, just doesn't seem like a [qf] bug.

Comment 9

[Daniel Holbert [:dholbert]]

(I'm leaning on comment 2 ("letting the OS shift deadlines") and comment 5 ("aligning timers across the OS...creates gaps of time where the CPU can enter low power mode") for the not-a-QF-bug judgement here.)

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

Note, when I made setTimeout(f,0) faster it did not improve speedometer at all.  Too me this kind of change would be better from a battery perspective and have less impact to responsiveness.