Quantum Flow Engineering Newsletter #7

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!
Posted in Blog Tagged with: , ,
5 comments on “Quantum Flow Engineering Newsletter #7
  1. Caspy7 says:

    The link next to Jan de Mooij’s name appears broken or wrong (for me).

  2. klop*cz says:

    These newsletters are great. Thank you and other people for all done efforts.
    It is a little bit pitty, that Quantum Flow project was not started much earlier, because it could persuade a lot of people not to leave FF. And obviously QF had positive impact on FF’s performance, because I perceive, that FF becomes better and better. Simply some actions are more responsive than before.

    • ehsan says:

      Well, firstly there are also a lot of other ongoing performance efforts right now, so QF can’t claim all of the credit. 🙂 But I’m glad to hear that you are perceiving improvements. You should also pay attention to the fact a lot of the work that is now bearing fruit has been in the works for many years. For example we spent many years moving to newer generations of JITs in the JavaScript engine, we moved from conservative stack scanning GC to generational precise GC, we separated the single process browser into multiple processes, we dealt with performance issues caused by binary code injected into Firefox and also misbehaving add-ons, etc. QF may be plugging some holes in some areas that we neglected but we also worked on many important areas at the same time. Trade-offs and limited resources make deciding what to work on really hard.

      • klop*cz says:

        Thank for reply. I and probably other users appreciate all your done efforts 🙂 Keep gping 🙂