Quantum Flow Engineering Newsletter #8

I hope you are still not tired of reading these! 🙂 If not, time for another quick update about the ongoing performance related work.
There are two important changes that have landed in Nightly. The first one is that Nightly (on Windows 32-bit builds) sends native stacktraces with background hang reports of 128ms or longer now. This change makes it easier to interpret the BHR data because now the Gecko Profiler pseudo stack traces are captured at the same time, rather than seconds apart, as I described two weeks ago. It also gives us a much broader perspective into what happens when Firefox Nightly behaves sluggishly on our user’s machines. The next step is to also split this into hangs that happen when the user is using the browser. And then we will start to triage those in the hopes of more directly improving the responsiveness of the browser. We have been using the current data either to file some new bugs or to corroborate some reported bugs for example where there was a profile attached. Recently at mconley’s suggestion we started to tag bugs with BHR evidence with [bhr] in the status whiteboard for easier classification. So far there aren’t many filed yet. Currently finding useful bug reports from this data set is fairly difficult and time consuming, and we could certainly use more help in this area.
The other important change that just landed was disabling non-multiprocess compatible add-ons in Nightly. I wrote about the importance of doing this last week. The adverse performance impact of these add-ons heavily skews our performance measurements on Nightly. I know that losing add-ons that you use is no fun (Nightly disabled a few of my own add-ons when I upgraded to the latest version this morning!) but I kindly ask you to please consider not re-enabling these extensions on Nightly. We know that WebExtension based add-ons are the future, and as Nightly users your help in suffering through a bit of a pain through this transition earlier in order to help us better understand where we are in improving the performance of the browser is much appreciated.
There are many great ongoing efforts to improve the performance of the browser in many areas. This week I want to highlight the great work that the front-end team has been doing. One example is the recent effort that Mike Conley, Neil Deakin and Florien Quèze have started to study and improve our startup times. The good news: it’s already working! Here is the graph of the ts_paint Talos showing the time that it takes to paint the initial window after startup starting to show steady improvements in the last 30 days!
Another example is the ongoing work to reduce the impact of synchronous reflows on the performance of the Firefox user interface. And then there is all of the great work under the Photon-Performance umbrella. And not to say anything about the upcoming Photon visual refresh project itself, which is being designed/implemented with performance in mind from scratch. And then there is the “miscellaneous stuff”, like the fact that as of a few days ago, closing tabs should be almost instant in Nightly, or how so far on the Firefox 55 cycle, the 95th percentile window restore 14-day moving median number is about 5 times faster than where we started in the beginning of the cycle:
Screenshot from 2017-05-04 23-36-47.png
Special thanks for the hard work of all of the people contributing to the front-end in every way! And now it’s time to acknowledge the work done in the past week. As always, I hope I’m including everyone!
Tagged with: , ,
5 comments on “Quantum Flow Engineering Newsletter #8
  1. Jack says:

    Thanks for making Firefox great again. 😀

  2. Alex says:

    I’ll never get tired of reading about improvements to firefox’s performance! 🙂

  3. Robbie says:

    Always look forward to and appreciate Quantum Flow engineering newsletters and These Weeks in Firefox posts :).

  4. manoj says:

    Team – this is great work. Thank you for gathering this data and posting a consolidated update.

    Question: How are you balancing the sometimes conflicting demands of performance and memory footprint? A number of changes were made to the browser during “Memshrink” to make Firefox lean. Some of the changes I have read over the last few weeks introduce new data structures and fields that enable quick lookup of state information.

    Is the team actively tracking memory usage on https://areweslimyet.com/?


    • ehsan says:

      Firstly I should mention that these two things always don’t end up on the opposite ends of the trade-off. In a surprising number of cases the fixes we are landing reduce code complexity, reduce memory usage and increase performance at the same time!

      But there are cases where we do trade off using more memory to make something faster. The traditional example is caching. To answer your question, we do actively track memory usage on AWSY, but things are actually a lot better. People have a good culture of asking the right questions about memory usage during design and code review and we also have an active ongoing MemShrink program. In general we try very hard to keep our memory usage as low as possible. That’s a super important aspect of a high quality browser engine since websites can be arbitrarily complex and they can basically throw arbitrary memory loads at you so you have to be as efficient as possible at everything. 🙂