Hi everyone, Next week, Nightly will switch to the 57 branch, beginning the development cycle of what will be the last train leaving the station towards Firefox 57. Around 5 months ago, I started <https://ehsanakhgari.org/blog/2017-03-09/quantum-flow-engineering-newsletter-1> writing the first one of these newsletters, which of course was well past when the Quantum Flow project got started. It's probably a good time for a retrospective on the way that we have come so far.
During this time, many small and medium size performance projects were started. Some are finished (and shipping even!) and some still ongoing, but the rate of progress has been quite astonishing. I have tried to talk about as many of these as possible in some detail in the newsletter, and these are only one part of the overall performance work happening. Here is a list of some of these projects with some overall status report: - We had a lot of reports of performance issues such as during page loads that were either caused or exacerbated by long running sync IPCs from the content to the chrome process. We started a focused effort to deal with this problem, which started from restricting the addition of new synchronous messages and gradually working towards removing the existing ones that were slow according to telemetry data. I've reported on the status of this work periodically, and it will probably be an ongoing effort for some more time, but we are well on the path of solving the majority of the severe issue that affects our users by Firefox 57 at this point. - The most important performance issues are the ones that affect the real users. In the past we had built an infrastructure for reporting backtraces from hangs that users experience through telemetry so that we can diagnose and fix them called Background Hang Reports, but this setup hadn't survived the passage of time. We started to stand up some python scripts to process the data coming through the telemetry servers to start getting actionable data while starting to create an awesome new UI <https://squarewave.github.io/> for it. Many thanks to Michael Layzell and Doug Thayer for their great work on this so far. Through this data, we have found and fixed <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL sw%3A"[bhr]"> a number of bugs. The rate of discovery and fixing bugs from this data has been slower than I would have liked. The reason is we didn't have enough engineers to look through this data and extract actionable bugs out of it. This process is still manual and very slow and time consuming. - We've kept up a rigorous process of continually measuring and tracking the performance of the browser in various workloads with the goal of identifying the most severe performance issues and eliminating them where possible. In order to get help from the broad group of engineers and contributors, it's important to communicate what issues we consider as the most critical, so we have created an active bug triage process to identify the most important bugs and you have all probably heard all about this by now. :-) This may sound like a lot of process, but after several months when I look back now at the rate of performance fixes that have landed as a result of this, I think this has been fairly effective. I think there has also been a lot about this triage process that we could have done better, like maintaining more consistency in prioritizing bugs, communicating more clearly about the criteria being used, etc. But time pressure and the sheer number of bugs to deal with forced the situation in a lot of cases anyway. - A few projects grew into their own independent parallel efforts. One example is some of the initial bugs that we had filed in various UI components in the front-end code started to emerge patterns that seemed to warrant some mini-projects formed around them. One example was synchronous layout and style flushes triggered by various code in the browser front-end (and sometimes by Gecko invoked by the front-end code), or various code such as timers going off at random time in the front-end code. Chasing issues like this is now part of the Photon Performance project and is being actively worked on, and the difference this is making is quite noticeable in the performance of various parts of the UI. Another example is reflow performance. We had seen expensive reflows in many profiles and even though we didn't have much concrete information about the sources of the problems, we reached out to the Layout team and asked for help. That resulted into an effort <https://bugzilla.mozilla.org/show_bug.cgi?id=FastReflows> to improve reflow performance, which is actively continuing. Thanks to both the front-end and layout teams for leading these efforts! - We have continued to improve the Gecko Profiler <https://perf-html.io/>. It is really impressive how far this effort has come. On the platform side, the profiler has become from unusable to 100% reliable on Win64. The UI keeps getting improved, and is very effective to use both for developers and users who want to help us by submitting profiles. We have also tried to work on some <https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Gecko_Profiler_FAQ> documentation <https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler> for profiling using it. Thanks to Markus Stange, David Major and Nick Nethercote who work on the back-end and Greg Tatum and Julien Wajsberg who work on the tool's front-end. - Since about 2 months ago <https://ehsanakhgari.org/blog/2017-06-02/quantum-flow-engineering-newsletter-11>, we started actively focusing on improving on the Speedometer 2 benchmark. Ben Kelly made some tweets this week about our progress on optimizing for this benchmark so far which are worth mentioning: "Firefox Nightly has gotten ~38% faster at speedometer v2 in the last 2 months. <https://twitter.com/wanderview/status/890292486471602176>" and "Firefox Nightly 56 is ~80% faster at speedometer v2 compared to currently released Firefox 54. <https://twitter.com/wanderview/status/890641643874926592>" This is great! But we aren't done yet. [image: Firefox Nightly 56 is ~80% faster at speedometer v2 compared to currently released Firefox 54] <http://ehsanakhgari.org/wp-content/uploads/2017/07/Screenshot-from-2017-07-28-01-06-45.png> In other performance related news this week, Stylo <https://wiki.mozilla.org/Quantum/Stylo>, our new parallel CSS engine written in Rust <https://www.rust-lang.org>, is ready for testing <https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-for-community-testing-on-nightly/> on the Nightly channel. I've been playing with it on my main browser profile for a while and so far I've been really liking what I'm seeing. I have gone to some pages where restyling cost typically shows up in profiles, and have added "StyleThread" to the list of threads in the Gecko Profiler settings, and have watched the parallel restyles happening in profiles, it's quite interesting. Especially when you see magic such as the Rust rayon threads calling into C++ code without any kind of synchronization on a background thread and the safety of this is ensured through static analysis <https://bugzilla.mozilla.org/show_bug.cgi?id=1294915>. We are indeed living in the future! It is so exciting that we're probably going to be the first browser engine deploying a parallel CSS engine through the superpowers of Rust, deploying this technology into the hands of millions of people. And now again it's time for the most important part of these newsletters, taking a moment to say thanks to those who helped make Firefox faster last week. Apologies to those of you who I'm forgetting to name here. - Thomas Nguyen made SafeBrowsing initialize in an idle callback once per session <https://bugzilla.mozilla.org/show_bug.cgi?id=1376591>, rather than once per window - Samael Wang got rid of the PBrowser::Msg_GetDPI sync IPC message <https://bugzilla.mozilla.org/show_bug.cgi?id=1350643>! - Kris Maglione optimized XPCOMUtils.generateQI() <https://bugzilla.mozilla.org/show_bug.cgi?id=1382904> and Components.utils.import() <https://bugzilla.mozilla.org/show_bug.cgi?id=1383215> for the cached module case. - Florian Quèze made most scripts in browser.xul load lazily <https://bugzilla.mozilla.org/show_bug.cgi?id=1381853>. - Jan de Mooij removed BytecodeAnalysis from IonBuilder <https://bugzilla.mozilla.org/show_bug.cgi?id=1382973>. This analysis showed up in some profiles, and its results could be obtained through other mechanisms. He also optimized Function.prototype.toString() <https://bugzilla.mozilla.org/show_bug.cgi?id=1383343>. - Henry Chang further optimized the IPC message size <https://bugzilla.mozilla.org/show_bug.cgi?id=1380974>, this time for smaller messages. Last week <https://ehsanakhgari.org/blog/2017-07-21/quantum-flow-engineering-newsletter-16> he had landed the initial optimizations for IPC message sizes. - Chris H-C refactored TelemetryHistogram internal storage <https://bugzilla.mozilla.org/show_bug.cgi?id=1366294>, solving some of the inefficiencies <https://bugzilla.mozilla.org/show_bug.cgi?id=1350765> in the previous code, as well as improving memory usage <https://treeherder.mozilla.org/perf.html#/alerts?id=8187>, among other benefits. - Alexander Poirot made DevTools initialization lazy <https://bugzilla.mozilla.org/show_bug.cgi?id=1359855>, which gave us some session restore wins <https://bugzilla.mozilla.org/show_bug.cgi?id=1359855#c154> on Talos. He also swapped out some code <https://bugzilla.mozilla.org/show_bug.cgi?id=1353656> from the WebIDE that was using the often-slow Add-on SDK. - Jon Coppeard fixed a bug where we could queue up many GC’s in a row <https://bugzilla.mozilla.org/show_bug.cgi?id=1374797> when doing off-main-thread parsing. - Ming-Chou Shih added a high priority queue for input events <https://bugzilla.mozilla.org/show_bug.cgi?id=1351148>. - Evelyn Hung implemented speculative connections to the selected search engine from the location bar <https://bugzilla.mozilla.org/show_bug.cgi?id=1355443> (the feature is currently disabled behind a pref.) - Jessica Jong optimized the NodeList object returned from getElementsByName() to actively ignore DOM elements that don’t have a name attribute <https://bugzilla.mozilla.org/show_bug.cgi?id=1376695>. She also replaced nsGenericHTMLFormElement::IsDisabled() with a boolean flag <https://bugzilla.mozilla.org/show_bug.cgi?id=1375599>. That virtual function regularly used to show up in profiles. - Kannan Vijayan added a CacheIR stub for optimizing Array.prototype.push() <https://bugzilla.mozilla.org/show_bug.cgi?id=1366375>, which enables the optimization of this operation in the baseline JIT. This is the continuation of his optimization efforts based on the data he is collecting from his rdtsc-based instrumented measurements of the top JS builtins used in Speedometer and general browsing <https://bugzilla.mozilla.org/show_bug.cgi?id=1365361>. - Ryan Hunt enabled keyboard asynchronous scrolling on all desktop platforms on Nightly <https://bugzilla.mozilla.org/show_bug.cgi?id=1377280>. Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
