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.