Quantum Flow Engineering Newsletter #14
We have about 13 more weeks before the train of Firefox 57 leaves the station. Next week many of you will be at the upcoming work week, so I thought it may be a good time to have some retrospection over our progress so far, just so that you can get a good sense of how to extrapolate when you are planning things next week.
One difficulty with the Quantum Flow project is that since it touches many different areas of the browser, it doesn’t lend itself very easily to drawing nice charts for it. 🙂 It is hard to find one metric that all of this work fits inside, and that’s OK. My goal this week is to highlight what we can achieve with focus in a limited amount of time, so I’ll bring a couple of examples.
This is a snapshot of our burndown chart1. We currently have 182 closed bugs and 136 open bugs. That’s great progress, and I’d like to thank everyone who helped with all aspects of this!
But to speak of a more direct measurement of performance, let’s look at our progress on Speedometer V2. Today, I measured our progress so far on this benchmark by comparing Firefox 53, 54, 55.0b3 (latest beta as of this writing) and the latest Nightly, all x64 builds, on the reference hardware. This is the result (numbers are the reported benchmark score, higher is better):
There are also many other top level performance related projects that are ongoing and approaching final stages. I’m really excited to see what the next few months are going to uncover for Firefox performance.
One bit of administrative note, as next week most people are able to get updates from each other face to face, I won’t send out the newsletter. Now let’s finish with this week’s list of acknowledgements to those who helped make Firefox faster during the past week, hopefully I’m not forgetting any names!
- Jan de Mooij optimized object property enumeration with great results. He finished his ongoing optimization effort on adding/defining properties. He also reordered the checks in ValueToId() and ValueToIdPure() to cover the more common cases first. He then moved the object/string pre-barrier null check to JIT code. This speeds up initializing unboxed objects.
- Makoto Kato improved the performance of HTMLInputElement.value setters by avoiding doing some unnecessary work.
- Alessio Placitelli deferred querying whether we’re the default browser to until after session restore completes in order to avoid potential startup slowdown issues.
- Markus Stange made arrow panel animations much more efficient on macOS!
- Doug Thayer made it so that we shrink the Places SQLite database off of the main thread, avoiding some jank when hitting memory pressure.
- Jonathan Kew switched to using a faster API for retrieving font glyph advances instead of all glyph metrics on DirectWrite.
- Mark Banner converted the bookmarks backup code to use the new asynchronous bookmarks API.
- Matthew Noorenberghe made the context menu code lazily import LoginManagerContextMenu.jsm and InlineSpellChecker.jsm at startup.
- Florian Quèze avoided attaching an XBL binding to hidden <xul:label> elements to improve startup performance.
- Boris Zbarsky avoided querying the preferences service to determine whether interface enablement conditions are met.
- Jonathan Watt optimized calls to nsUXThemeData::InitTitlebarInfo(), improving the performance of opening a window on Windows.
- Nicholas B. Pierron enabled backtracking to a normal call when inlining fails in IonMonkey.
- Mats Palmgren continued his battle on unnecessary hashtable lookups. He added a couple of new APIs for adding and removing entries on nsTHashtable which return values indicating whether they changed the hashtable, which allow rewriting patterns where code currently does two hashtable lookups, first to check whether an entry exists in the hashtable and then to add/remove it (which incurs a second lookup on the same entry). He then followed up with various fixes to reduce duplicate hashtable lookups. He also devirtualized nsTableCellFrame::GetRowSpan/GetColSpan().
- Andreas Farre exposed the idle dispatch API with timeout to chrome JS.s This is the final remaining bit of API that brings chrome JS to parity with C++ in terms of its ability to use the new idle dispatch facilities.
- Cervantes Yu moved our in-process crash reporter to use off-main-thread IO for generating the crash minidump. This means that our UI will now remain responsive if a tab crashes while we prepare the corresponding crash report.
- Makoto Kato made UpdateOverlayTextVisibility() not get called twice by the HTMLInputElement.value setter when the element has focus.
- Edgar Chen made document.hidden be set to true when the browser window is fully covered by another non-translucent application. This has some performance benefits such as treating such pages as if they were in a background tab and throttling down timeouts/refresh driver for them.
- Jean-Yves Avenard added support for texture recycling to the ffmpeg media backend on Windows.
- Kirk Steuber made us clone attributes rather than reparse them when possible when cloning a node.
- Olli Pettay made nsTextEditorState::UpdateOverlayTextVisibility() avoid accessing the preferences service every time.
- Doug Thayer moved storage cache shrinking to happen off the main thread.
- Jon Coppeard changed Zone::isGCMarking() to avoid a TLS lookup.
- Yoshi Huang moved nsImageLoadingContent to the Necko AsyncOpen2 API which, among security benefits, also reduced the cost of loading images by removing some security checks which happen centrally at the networking layer now.
- Lee Salzman optimized box blur surfaces for destination draw targets. This helps with the performance of YouTube videos with text overlays using box shadows, which is common.
- Dão Gottwald avoided a layout flush in order to determine whether scrollbox scroll buttons should be enabled/disabled.
- Ted Campbell improved JIT support for ES6 classes. Made nice improvements to the ARES-6 benchmark!
 (The number of bug fixes is a weird metric to use for performance improvements, since we use bugs as a unit of work, and the performance impact of each bug can be vastly different. But I have tried to describe the details of these bugs for the most part before so the detailed information is at least available.)