Bugzilla

Thanks for the feedback Florian. I had thought that 100ms would be too high and that I would see some kind of artifacts but I wanted to test in an extreme case to see how noticeable the delays would be (and to try and suss out any bugs where clients were implicitly relying on a certain response time for correctness). I also tested at 10s and 1s to verify that my change _could_ have an observable impact and a decrease in responsiveness of some things was clearly evident at those levels.

I also figured out what was happening with the frequent wake-ups and it was mostly due to a problem that I introduced with my PoC - in the case where there were no pending timers I ended up requesting to sleep for a negative amount of time (due to overflow/wrap-around in TimeDuration) which, of course, caused TimerThread to wake up back up almost immediately. Once I fixed that the numbers that I was tracking started being more as expected.

So now I'm been mostly messing around with measuring what the impact is of delaying timers in reducing the number of wake-ups. To that end, I've started by measuring the number of wake-ups required to service a fixed number (2000 in my tests) of timers. Going from the current behavior (a 0ms wake-up delay) to a fixed 10ms wake-up delay results in a 6.8% decrease in the number of wake-ups needed. Going from the current behavior to a fixed 100ms delay results in a 31.8% decrease.

A 31.8% seems pretty nice but a possible 100ms delay in firing a timer might be too much for at least some timers (while probably completely acceptable for others),

Next I am going to compute the wake-up delay based on the actual timers that are pending so that we won't wait any more than is actually necessary to bundle additional timers into the same wake-up.

In order to determine the impact of that change I'm going to start tracking the mean (and maybe the RMS) delay between when a timer requested to fire and when it actually fires to see how that changes.


As a side note, I'm not really sure if the Javascript timers go through/use TimerThread at all. I had initially thought that the JS timers were the primary use case (for this work and for TimerThread in general) but, I haven't seen any evidence that this is the case and, based on some code exploration that Doug and I did a couple weeks ago, it seems that the JS timers are going through https://searchfox.org/mozilla-central/source/dom/base/TimeoutManager.cpp. Am I missing a connection between the two? (Granted I haven't spend a lot of time looking at TimeoutManager.)

Thanks for the feedback Florian. I had thought that 100ms would be too high and that I would see some kind of artifacts but I wanted to test in an extreme case to see how noticeable the delays would be (and to try and suss out any bugs where clients were implicitly relying on a certain response time for correctness). I also tested at 10s and 1s to verify that my change _could_ have an observable impact and a decrease in responsiveness of some things was clearly evident at those levels.

I also figured out what was happening with the frequent wake-ups and it was mostly due to a problem that I introduced with my PoC - in the case where there were no pending timers I ended up requesting to sleep for a negative amount of time (due to overflow/wrap-around in TimeDuration) which, of course, caused TimerThread to wake up back up almost immediately. Once I fixed that the numbers that I was tracking started being more as expected.

So now I'm been mostly messing around with measuring what the impact is of delaying timers in reducing the number of wake-ups. To that end, I've started by measuring the number of wake-ups required to service a fixed number (2000 in my tests) of timers. Going from the current behavior (a 0ms wake-up delay) to a fixed 10ms wake-up delay results in a 6.8% decrease in the number of wake-ups needed. Going from the current behavior to a fixed 100ms delay results in a 31.8% decrease.

A 31.8% seems pretty nice but a possible 100ms delay in firing a timer might be too much for at least some timers (while probably completely acceptable for others), so some more investigation will be needed here to determine what can actually be rolled out.

Next I am going to compute the wake-up delay based on the actual timers that are pending so that we won't wait any more than is actually necessary to bundle additional timers into the same wake-up.

In order to determine the impact of that change I'm going to start tracking the mean (and maybe the RMS) delay between when a timer requested to fire and when it actually fires to see how that changes.


As a side note, I'm not really sure if the Javascript timers go through/use TimerThread at all. I had initially thought that the JS timers were the primary use case (for this work and for TimerThread in general) but, I haven't seen any evidence that this is the case and, based on some code exploration that Doug and I did a couple weeks ago, it seems that the JS timers are going through https://searchfox.org/mozilla-central/source/dom/base/TimeoutManager.cpp. Am I missing a connection between the two? (Granted I haven't spend a lot of time looking at TimeoutManager.)