Hi everyone, With around three weeks left in the development cycle for Firefox 57, everyone seems to be busy getting the last fixes in to shape up this long-awaited release. On the Quantum Flow project, we have kept up with the triage of the incoming bug reports that are tagged as [qf], and as we're getting closer to the beta uplift date, the realistic opportunity for fixing bugs is getting narrower, and as such the bar for prioritizing incoming bug reports as [qf:p1] keeps getting higher. This matches with the overall shift in focus in the past few weeks towards getting all the ongoing work that is targeting Firefox 57 under control to make sure we manage to do as much of what we have planned to do for this release as possible.
This past week we made more progress on optimizing the performance of Firefox for the Speedometer V2 <https://mozilla.github.io/arewefastyet-speedometer/2.0/> benchmark. Besides many of the usual optimizations, which you will read about in the acknowledgement section of the newsletter, one noteworthy item was David Major's investigation <https://bugzilla.mozilla.org/show_bug.cgi?id=1356652> for adding this benchmark to the set of pages that we load to train the PGO profile we use on Windows builds. This allowed the MSVC code generator to generate better optimized code using the profile information and bought us a few benchmark score points. Of course, earlier similar attempts <https://bugzilla.mozilla.org/show_bug.cgi?id=1096280> hadn't really gained us better performance, and it's unclear whether this change will stick or get backed out due to PGO specific crashes or whatnot, but in the mean time we're not stopping landing other <https://bugzilla.mozilla.org/show_bug.cgi?id=1339557> improvements <https://bugzilla.mozilla.org/show_bug.cgi?id=1245279> to Firefox for this benchmark either! At the time of this writing, the Firefox Health Dashboard puts our benchmark score on Nightly at 4.07% of Chrome's. Another news worthy of mention related to Speedometer is that recently Speedometer tests with Stylo <https://wiki.mozilla.org/Quantum/Stylo> were enabled <https://bugzilla.mozilla.org/show_bug.cgi?id=1392123> on AWFY. As can be seen on the reference hardware <https://www.amazon.com/dp/B01K1IO3QW> score page <https://arewefastyet.com/#machine=36&view=single&suite=speedometer-misc&subtest=score>, Stylo builds are now a bit faster than normal Gecko when running Speedometer. This has been achieved by the hard work of many people on the Stylo team and I'd like to take a moment to thank them, and especially call out Bobby Holley who helped make sure that we have a great performance story here. In other performance related news, this past week the first implementation of our cooperative preemptive scheduling of web page JavaScript <https://bugzilla.mozilla.org/show_bug.cgi?id=1350432>, more commonly known as Quantum DOM, landed. The design document <https://docs.google.com/document/d/1MZhF1zB5_dk12WRiq4bpmNZUJWmsIt9OTpFUWAlmMyY/edit> describes some of the background information which may be helpful if you need to understand the details of how the new world looks like. For now, this feature is disabled by default while the ongoing work to iron out the remaining issues continues. The Quantum DOM project has been a massive overhaul of our codebase. A huge part of it has been the "labeling" <https://wiki.mozilla.org/Quantum/DOM#Labeling> project that Bevis Tseng has been tirelessly leading for many months now. The basic idea behind this part of the project is to give each runnable a name and indicate which tab or document the runnable is associated with (I'm simplifying a bit, please see the wiki page <https://wiki.mozilla.org/Quantum/DOM#Labeling> for more details.) Bill McCloskey had a great suggestion about some performance lessons that we have learned through this project for the performance story section of this newsletter, which was to highlight how this project ended up uncovering some unexpected performance issues in Firefox! Bevis has some telemetry analysis <https://gist.github.com/bevis-tseng/d8a918cb53112a82357c872ce15ee790> which measures the number of runnables of a certain type (to view the interesting part, please scroll down to the "full runnable list" section). This analysis has been used to prioritize which runnables need to be worked on next for labeling purposes. But as this list shows the relative frequencies of runnables, we've ended up finding several surprises in where some runnables are showing up on this list, which have uncovered performance issues which would otherwise be very difficult to detect and diagnose. Here are a few examples (thanks to Bill for enumerating them!): - We used to send the DidComposite notification to every tab, regardless of whether it was in the foreground or background. We tried to fix this once <https://bugzilla.mozilla.org/show_bug.cgi?id=1337548>, but the fix actually only fixed a related issue involving multiple windows. The real fix finally got fixed later <https://bugzilla.mozilla.org/show_bug.cgi?id=1349991>. - We used to have a "startup refresh driver" which used to have only for a few milliseconds during startup. However, it was showing up as #33 on the list of runnables. We found out <https://bugzilla.mozilla.org/show_bug.cgi?id=1384300> that it was never being disabled after it was being started, so if we ever started running the startup refresh driver, it would run indefinitely in that browsing session, and get to the top of the list. Unfortunately, while this runnable disappeared for a while after that bug was fixed, it is now back and we're not sure why. - We found out that MediaStreamGraphStableStateRunnable is #20 on this list, which was surprising as this runnable is only supposed to be used for WebRTC and WebAudio, neither being extremely popular features on the Web. Randell Jesup found out that there is a bug <https://bugzilla.mozilla.org/show_bug.cgi?id=1395012> causing the runnable to be continually dispatched after a WebRTC or WebAudio session is over. - We run a runnable for the intersection observer feature a lot. We tried <https://bugzilla.mozilla.org/show_bug.cgi?id=1332100> to cut the frequency of this runnable once, but it doesn't seem to have helped much. This runnable still shows up quite high on the list, as #6. I encourage people to look at the telemetry analysis <https://gist.github.com/bevis-tseng/d8a918cb53112a82357c872ce15ee790> to see if they can spot a runnable with a familiar name which appears too high on the list. It's very likely that there are other performance bugs lurking in our codebase which this tool can help uncover. Now, please allow me to take a moment to acknowledge the hard work of everyone who helped make Firefox faster this past week. I hope I'm not forgetting any names! - Mike Conley made it so that background tabs are “warmed up” when hovering the mouse cursor over them <https://bugzilla.mozilla.org/show_bug.cgi?id=1385453>. This should improve tab switching perceived performance. - Samael Wang made it so that focus changes don’t cause sync IPC messages <https://bugzilla.mozilla.org/show_bug.cgi?id=1349255> for IME, which should help reduce UI jank. - Masayuki Nakano optimized retrieving the selection from nsTextEditorState <https://bugzilla.mozilla.org/show_bug.cgi?id=1393348>. He also optimized nsTextEditorState::GetValue() <https://bugzilla.mozilla.org/show_bug.cgi?id=1395146>. He also made Selection cache a Range object under some circumstances instead of recreating it <https://bugzilla.mozilla.org/show_bug.cgi?id=1393816> if possible. In addition, he made nsContentEventHandler not use nsRange objects for representing two DOM points <https://bugzilla.mozilla.org/show_bug.cgi?id=1375502>, as these objects can have a high performance cost. Last but not least, he made sure EditorBase::EndPlaceholderTransaction() doesn’t retrieve an nsCaret object needlessly <https://bugzilla.mozilla.org/show_bug.cgi?id=1395157>. These are all part of the continued effort to reduce the cost of setting the value attribute of input text controls <https://bugzilla.mozilla.org/show_bug.cgi?id=1346723>. - Kris Maglione used the subscript loader to load the browser.xul scripts <https://bugzilla.mozilla.org/show_bug.cgi?id=1384714> instead of the script tag. - Wei-Cheng Pan added a new telemetry probe for measuring startup input latency based on the user’s notion of when a session becomes interactive <https://bugzilla.mozilla.org/show_bug.cgi?id=1373814> (which is calculated based on when the first tab is displayed after startup.) - Bill McCloskey landed the initial implementation of cooperative preemptive scheduling of web page JS in the same content process <https://bugzilla.mozilla.org/show_bug.cgi?id=1350432> (aka Quantum DOM scheduling). This implementation is currently intended for testing and is disabled by default. - David Major, with the help of Gregory Szorc and Ryan VanderMeulen added the Speedometer V2 benchmark to our Windows PGO profile phase training set <https://bugzilla.mozilla.org/show_bug.cgi?id=1356652>, which improved our benchmark score by assisting the compiler at generating better optimized code. - Nicholas Hurley ensured that the network predictor only parses URIs when needed <https://bugzilla.mozilla.org/show_bug.cgi?id=1390274>. - Nathan Froyd eliminated a virtual call when querying whether an XPCOM-style weak pointer is alive <https://bugzilla.mozilla.org/show_bug.cgi?id=1390568> by making nsQueryReferent not be an nsCOMPtr_helper. He also manually devirtualized nsIWeakReference::QueryReferent() <https://bugzilla.mozilla.org/show_bug.cgi?id=1393592> which was the second virtual call that we used to incur when checking such weak pointers. - Thom Chiovoloni optimized the Quote() function <https://bugzilla.mozilla.org/show_bug.cgi?id=1343005> which was the bottleneck in JSON.prototype.stringify. - Samael Wang removed the PBrowser::NotifyIMEFocus synchronous IPC message <https://bugzilla.mozilla.org/show_bug.cgi?id=1349255>. - Jan de Mooij finished his mini-project of removing the getProperty/setProperty hooks from SpiderMonkey ClassOps <https://bugzilla.mozilla.org/show_bug.cgi?id=1389510>. This entailed fixing the consumers that were relying on these hooks in the dependencies of the bug, and removes some of the overhead from invoking getter/setters where before we needed to handle these hooks. He also optimized property addition even further <https://bugzilla.mozilla.org/show_bug.cgi?id=1394365>. - Olli Pettay optimized HasRTLChars() usage <https://bugzilla.mozilla.org/show_bug.cgi?id=1394719>. He also made the two-byte character variant of nsTextFragment use an nsStringBuffer <https://bugzilla.mozilla.org/show_bug.cgi?id=1393232> so that its string data can be obtained without copying memory. - Till Schneidereit helped finish André Bargull’s original patch to move parts of Object.getOwnProperty and Object.defineProperty to self-hosted code <https://bugzilla.mozilla.org/show_bug.cgi?id=1303335> in order to improve their performance. - Bas Schouten cached the reference frame when building a display list to make GetScrolledRect() faster and switched to estimate the scale of frames based on their PresShell resolution <https://bugzilla.mozilla.org/show_bug.cgi?id=1363922>. - Robert Wood fixed capturing profiles from Talos using a trychooser syntax <https://bugzilla.mozilla.org/show_bug.cgi?id=1390084>. - Shane Caraveo removed the WebRequest:ShouldLoad synchronous IPC message <https://bugzilla.mozilla.org/show_bug.cgi?id=1393909>. Cheers, -- Ehsan _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
