We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
We can go through quite a few more timers these days, since timers are stored now in an array and iterating through that is fast.
Also, relying on timer value for another thread or low priority timers does prevent idle tasks to run in some cases, and now that more timers
are iterated through, that behavior can be tweaked.
For RefreshDriver this is taking the simple approach and just let idle tasks to run if RefreshDriver isn't ticking. We do start RefreshDriverTimer pretty
much always when something in DOM or layout is changing.
Differential Revision: https://phabricator.services.mozilla.com/D189909
- Prior to this change, we allowed any timer *except* the first to fire early. Being woken up
slightly before our first timer is due was resulting in a lot of "wasted" wake-ups (where we wake
up and do nothing other than go back to sleep).
- This change results in waking up TimerThread 10% less frequently in my test case of watching a
YouTube video.
- Made the allowed early firing tolerance be a constant value rather than calculated at run-time.
- Also cleaned up some includes.
Differential Revision: https://phabricator.services.mozilla.com/D184017
- Prior to this change, we allowed any timer *except* the first to fire early. Being woken up
slightly before our first timer is due was resulting in a lot of "wasted" wake-ups (where we wake
up and do nothing other than go back to sleep).
- This change results in waking up TimerThread 10% less frequently in my test case of watching a
YouTube video.
- Made the allowed early firing tolerance be a constant value rather than calculated at run-time.
- Also cleaned up some includes.
Differential Revision: https://phabricator.services.mozilla.com/D184017
The timeout of the next timer is a good proxy for when we are planning
to wake up for as long as we are always intending to wake-up for the
next timer but that is going to stop being the case soon.
Differential Revision: https://phabricator.services.mozilla.com/D173102
Really we want to wake-up the Timer Thread now if the newly-added timer
wants to fire before the Timer Thread was scheduled to wake up. The
previous logic happened to work correctly under previous insertion
behavior isn't correct now.
Differential Revision: https://phabricator.services.mozilla.com/D168496
Due to the possible presence of canceled timers at the "front" of the
list, mTimers[0] won't necessarily hold the next timer to be fired
unless we've cleaned up those front timers recently.
Differential Revision: https://phabricator.services.mozilla.com/D166575
The previous version used IndexOfFirstElementGt which is implemented
with a binary search. That doesn't work correctly because the mTimers
array that is being searched is maintained in sorted order
*only if the "cancelled" timers are skipped*. This revision replaces the
binary search with a linear search which can handle this without
problem. Given that the number of timers present at any one time is
fairly modest, a linear search is probably a more appropriate choice
anyway.
Also added a new function, VerifyTimerListConsistency, which is called
once per wake-up in the main loop and enabled only in DEBUG builds, that
checks mTimers for ordering and consistency.
Differential Revision: https://phabricator.services.mozilla.com/D164294
This makes the code more complex, but it is needed to keep this most-used
function efficient related to its old implementation using `std::push_heap`.
Differential Revision: https://phabricator.services.mozilla.com/D164292
Inserting elements in the sorted array is more costly than pushing to a binary
heap, but this is balanced by the removal of indirections and de/allocations,
and the upcoming re-use of empty entries.
In the end, this change is necessary to allow future improvements like timer-
coalescing, where we'll need to see multiple timers in order.
Bonus: FindNextFireTimeForCurrentThread changes a lot, because it used to have
to `pop_heap` elements and then `push_heap` them back! (Sometimes resulting in
subtle changes for timers with the same timeout.) So this one benefits the
most.
Differential Revision: https://phabricator.services.mozilla.com/D164291
So entries now store the given timeout value (instead of clamping it to after "now").
And we store this timeout first, as it's accessed more frequently.
Differential Revision: https://phabricator.services.mozilla.com/D164288
Justin Link