It's time for another quick update about the recent Quantum Flow work.

I want to start by shedding some light into the performance of synchronous IPC caused by JavaScript.  Here is a breakdown report for data as of today similar to the previous ones.  Let's look at the top 10 worst offenders:

  • All of the ones with names starting with Addons: or Content: are e10s compatibility shims that we have been using to make non-e10s compatible add-ons work with Firefox.  They essentially make synchronous XPCOM APIs work using sync IPC across process boundaries.  This is by far the majority of the issue here, and it skews all sorts of performance measurements that we do on Nightly.  We're soon going to make changes to Nightly to disable running non-e10s compatible extensions so that we get better performance data.
  • The second one is AdblockPlus:Message which presumably comes from one of the the Adblock Plus extension variants.  What's curious about this one is the super high count of the messages, the median time isn't that high.  And that the submission percentage is 100%!!
  • #9 is contextmenu.

Looking through more of these messages, there are a few more that stem from our code.  It's a bit hard to spot everything due to everything being mixed together.  After traditional style extensions aren't loaded any more a lot of these issues will go away but it also makes things difficult to evaluate when looking at the data.  This is also solid practical data that can be used as input to API design in the future, on why some functionality such as sync IPC is very dangerous to be exposed at the API level in the first place!  Moving to a more modern extension model is really good for performance from this perspective.

The next topic I wanted to discuss was the issue of the usage of timers in our code.  Timers are terrible for responsiveness and are almost never what you want.  We sometimes use them to lazify some work (do this part of the initialization in 10 seconds!) or to do some periodic background task (refresh this cache every second) but they cause a lot of problems due to the fact that they can execute at unpredictable times.  From the perspective of improving the responsiveness of Firefox, if your goal is to keep the main thread as free as possible when the user's input events are about to be handled, the last thing you want is to start running one of these timers right before the user clicks or types or something like that.  Gecko now supports the requestIdleCallback API which allows the caller to request a timer that only gets dispatched when the application is idle.  Where possible, you should consider re-examining the timers in your areas of the code and consider using to idle dispatch where appropriate.  Note that this API is currently only available to contexts where the Window object is available.  Bug 1358476 is adding the functionality to nsThread and hopefully we can expose it to JSMs afterwards as well.

On to the list of the acknowledgements for the week.  As usual, I hope I'm not forgetting anyone's names here!