Quantum Flow Engineering Newsletter #11

Keeping track of ongoing progress and how much more work different areas need is important.  I’ve found the new Firefox Health Dashboards that Harald Kirschner and the team have worked on extremely helpful.  You can see the status of the ongoing work on the various areas on the Quantum project there, including the Quantum Flow project.
The other charts that I’ve been watching are the Speedometer v2 benchmark charts (32-bit and 64-bit Windows).  We are actively working on improving our score on this benchmark.  In case you haven’t heard about this benchmark before, it runs a number of simulated user actions in the TodoMVC app written in a number of popular JS frameworks/dialects and computes a score based on that.  It mostly examines the JavaScript engine of the browser but since it runs the code in the real browser environment it ends up examining other parts of the browser (DOM, layout, graphics, etc.) to certain extents too.  If you would like to keep up with our progress on this benchmark, one nice way is to follow the tracker bug for the optimization work around this.
One important project that is now starting to get to bear fruit is the refactoring of Gecko’s event queue.  See the following diagram which I borrowed from this brownbag talk about Quantum DOM.


​​The basic idea is that we want to process events with a different order depending on their type, but we don’t want to change the respective ordering of the events of the same type.  This will allow Gecko to serve requests to paint pages and handle user input events first, and then process other things like scripts, DOM events, timer callbacks, network events, etc., and finally when there is no other immediate work of higher priority to be done, low priority work such as garbage and cycle collection and idle callbacks are run.  This is now mostly finished (except for high priority input events), and we have already started porting a few things to run as idle callbacks!  This part of Quantum DOM will hopefully be part of Firefox 55.
The idle callbacks are a great programming utility for asynchronous callbacks that you would like to run with a low priority and without them interfering with important work.  These are already exposed to web pages.  In C++, you can schedule such callbacks using the NS_IdleDispatchToCurrentThread() API.  In Chrome JS, the equivalent is the nsIThread.idleDispatch() method.  We will soon write some more thorough documentation on how this can be used in both Gecko and browser code.  We now have a lot of bugs on file which can use idle dispatch as a solution or mitigation, so this will be a useful trick for people to get familiar with.
Last week, we had a small work week at the Toronto office.  The week was more focused on bug fixing than long-term planning (we only have around 16 more weeks of development time on mozilla-central for Firefox 57 after all!) so you can probably see more of the progress on the burndown chart.  We had a big triage on the last day where we went through most of the [qf:p1] bugs and removed a number of them from the set which were now no longer high priority issues or issues we had no realistic hopes of being able to fix in the 57 timeframe given the staffing available.
Now as always it’s time to recognize the efforts of many of you who have helped make Firefox faster in the past 2 weeks.  Apologies in advance to those whose contributions I’m forgetting to acknowledge here.
  • Kris Maglione took his off-thread script decoding infrastructure designed to improve startup performance to a new level!  You may remember this setup was introduced just recently, and now Kris taught it how to decode multiple scripts at a time, to save the cost of off-thread script decoding setup per script.  It should be obvious in the graph below from ts_paint measurements when the patches landed!

Posted in Blog Tagged with: , ,
8 comments on “Quantum Flow Engineering Newsletter #11
  1. Jérôme says:

    Hi,

    Thanks for this newsletter, very interesting! I was wondering, is this work based exclusively on the Windows platform or do you also test/work on Linux/android/Mac?

    Thanks,

    Jérôme

    • ehsan says:

      We currently mostly focus on Windows, but still some measurement is done on other platforms as well. We try to focus our energy on platforms where our users are, but thankfully most of our code is cross-platform so many of our code changes affect many platforms.

  2. Caspy7 says:

    Noticed a few small grammar errors/typos:
    “since it reals the code in the real browser environment”
    “the is the equivalent”
    “attempts to focus() and element”
    “table frames get they own display items”
    “allowing us deal better with polymorphic code”

  3. sciguyryan says:

    Thanks for doing these updates, it’s really nice to see how things are progressing!

    If it’s of any use to anyone I’ve setup a Bugzilla query to list the P1 bugs – https://bugzilla.mozilla.org/buglist.cgi?cmdtype=runnamed&namedcmd=Quantum%20Flow%20P1

  4. Hello!
    Thank you very much for this summary! I wanted to ask a question. As far I understand, the current plan is to land bug 1351148 with high priority input events (part of Quantum DOM project) before Beta 55 rides the train on June 13th?

    • ehsan says:

      Hi, I’m not sure what the exact plans are for that bug, but the development cycle for Firefox 55 is almost over, this is the final week of the development cycle, so that bug is almost definitely going to miss the Firefox 55 cycle, and will need to wait for a later train (perhaps Firefox 56, we’ll see!)