Hi everyone, 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1346415> 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 <https://ehsanakhgari.org/blog/2017-04-21/quantum-flow-engineering-newsletter-6>. It also gives us a much broader perspective into what happens when Firefox Nightly behaves sluggishly on our user's machines. The next step <https://bugzilla.mozilla.org/show_bug.cgi?id=1353440> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1354389> some new bugs or to corroborate <https://bugzilla.mozilla.org/show_bug.cgi?id=1354143> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1354389>. 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 comypatible add-ons <https://bugzilla.mozilla.org/show_bug.cgi?id=1356462> in Nightly. I wrote about the importance of doing this last week <https://ehsanakhgari.org/blog/2017-04-28/quantum-flow-engineering-newsletter-7>. 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1355956>. 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! <https://treeherder.mozilla.org/perf.html#/graphs?timerange=2592000&series=%5Bautoland,21e21680dac530b424eb1f3fff666d92c2929104,1,1%5D&series=%5Bautoland,2b1d3ea8736e7fadcd5c3aec5749366bc1770257,1,1%5D> Another example is the ongoing work to reduce the impact of synchronous reflows <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%2B%20sw%3A%22[ohnoreflow]%22> on the performance of the Firefox user interface. And then there is all of the great work under the Photon-Performance umbrella <https://bugzilla.mozilla.org/show_bug.cgi?id=1348289>. And not to say anything about the upcoming Photon visual refresh <https://bugzilla.mozilla.org/show_bug.cgi?id=1325171> 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 <https://bugzilla.mozilla.org/show_bug.cgi?id=1336763> 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: [image: Screenshot from 2017-05-04 23-36-47.png] <https://health.graphics/quantum/track?metric=FX_SESSION_RESTORE_RESTORE_WINDOW_MS> 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! - Doug Thayer added a WebExtension API <https://bugzilla.mozilla.org/show_bug.cgi?id=1326572> to nsIProfiler, and is very close to shipping a WebExtension version of the Gecko Profiler Add-on <https://github.com/devtools-html/Gecko-Profiler-Addon/pull/44>. This will help reduce Add-on SDK noise in captured profiles, and ensures that the Profiler Add-on will be available during and after Firefox 57 <https://wiki.mozilla.org/Add-ons/Firefox57>! - Mike Conley made it so that we don’t do a potentially expensive IPC round-trip <https://bugzilla.mozilla.org/show_bug.cgi?id=1336763> when closing tabs in the common case. This should help make closing tabs faster. He wrote a blog post about it too. <https://mikeconley.ca/blog/2017/05/01/making-tabs-close-faster-in-multi-process-firefox/> - David Anderson made the compositor on Windows front-load shader loading <https://bugzilla.mozilla.org/show_bug.cgi?id=1360766> so that it’s more ready to composite things when the first layer tree gets uploaded. - Michael Layzell made it so that we can get more native stacks <https://bugzilla.mozilla.org/show_bug.cgi?id=1346415> via the Background Hang Reporter! This will greatly enrich the data that Telemetry gathers to let us know when things are slow. He also made sure that the pseudo and native stacks are captured in the same tick <https://bugzilla.mozilla.org/show_bug.cgi?id=1358619>. - David Baron made nsFrame::FinishAndStoreOverflow call nsIFrame::StyleDisplay less <https://bugzilla.mozilla.org/show_bug.cgi?id=1352056>, making layout more efficient in certain scenarios. - Neil Deakin added a way to batch potentially-expensive XUL command updates into a single call, and then made sure our tab switching <https://bugzilla.mozilla.org/show_bug.cgi?id=1354564> and menu panel opening code <https://bugzilla.mozilla.org/show_bug.cgi?id=1356587> uses it. He also made a reflow far less common <https://bugzilla.mozilla.org/show_bug.cgi?id=1354956> when showing tooltips on non-remote content (like the about:newtab page). - Nicholas Hurley made it so that we speculatively connect to servers when the mousedown event occurs on links <https://bugzilla.mozilla.org/show_bug.cgi?id=1348278> to improve perceived performance of page navigation. - Neerja Pancholi got rid of some redundant calls to nsIFrame::StyleDisplay <https://bugzilla.mozilla.org/show_bug.cgi?id=1361207> for a nice layout efficiency win. - Tom Schuster optimized the JavaScript typeof operator <https://bugzilla.mozilla.org/show_bug.cgi?id=1350263> when applied to Objects - Andrew Swan landed patches to disable add-on shims on Nightly <https://bugzilla.mozilla.org/show_bug.cgi?id=1352204>! This will greatly reduce the amount of noise in profiles and Background Hang Reporter data caused by our (well-intentioned, but tragically slow) shimming layer. - Wei-Cheng Pan added telemetry for input event handling latency <https://bugzilla.mozilla.org/show_bug.cgi?id=1345540>. - Edouard Oger got rid of some expensive Sync code <https://bugzilla.mozilla.org/show_bug.cgi?id=1358648> that was running before the first window was painted, and some other Sync code that was loading for every new window <https://bugzilla.mozilla.org/show_bug.cgi?id=1353571> resulting in a 3% improvement on the tpaint Talos test on Windows <https://bugzilla.mozilla.org/show_bug.cgi?id=1353571#c67>. - Ted Campbell optimized the JavaScript in operator in IonMonkey <https://bugzilla.mozilla.org/show_bug.cgi?id=1337773>. - Patrick McManus made sure that we initialize the Windows networking stack off of the main thread <https://bugzilla.mozilla.org/show_bug.cgi?id=1361495> on start-up. - Kris Maglione made a bunch of code that runs in nsBrowserGlue before the first window is shown load lazily instead <https://bugzilla.mozilla.org/show_bug.cgi?id=1358921>! This should improve our start-up performance. Talos agrees <https://bugzilla.mozilla.org/show_bug.cgi?id=1358921#c74>. Kris also fixed the displaying of remote XUL browser panels in XUL popups <https://bugzilla.mozilla.org/show_bug.cgi?id=1353060>. This is a blocker of out-of-process WebExtensions <https://bugzilla.mozilla.org/show_bug.cgi?id=1190679>, which is highly desirable for improving the performance of the parent process by reducing the impact of installed add-ons (including our own add-ons perhaps!) - Kannan Vijayan got rid of patchable GC pre-barriers <https://bugzilla.mozilla.org/show_bug.cgi?id=1358599>. Patching these barriers required two mprotects. - Florian Quèze got rid of some main thread IO on start-up on Windows <https://bugzilla.mozilla.org/show_bug.cgi?id=1361087>, which should also boost our start-up performance. - Gabor Krizsanits enabled the Pre-allocated Process Manager by default <https://bugzilla.mozilla.org/show_bug.cgi?id=1341008>, which should improve perceived performance when opening new tabs or windows that would normally allocate a new content process on the fly. - Kevin Jones fixed a recent regression causing all lazybrowsers to be eagerly instantiated <https://bugzilla.mozilla.org/show_bug.cgi?id=1360940>. - Evelyn Hung improved the years-old heuristics of the spell checker to improve typing responsiveness <https://bugzilla.mozilla.org/show_bug.cgi?id=1354641>. These heuristics, besides being old, were actively harmful for performance in e10s. - Shane Caraveo removed an unnecessary call to the SocialService.getProvider() function <https://bugzilla.mozilla.org/show_bug.cgi?id=1359851> during startup. - Ben Kelly and Boris Zbarsky (a couple of weeks ago) optimized the data structures of the timer thread <https://bugzilla.mozilla.org/show_bug.cgi?id=1325254>. Boris noticed the slowness in a profile <https://bugzilla.mozilla.org/show_bug.cgi?id=1354616> and realized Ben had patches pending review comments being addressed, and he helped land them. Until next time, happy hacking! Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
