Quantum Flow Engineering Newsletter #10

[Ehsan Akhgari]

Hi everyone,

Let's start this week's updates with looking at the ongoing efforts to
improve the usefulness of the background hang reports data. With Ben
Miroglio's help, we confirmed
<https://gist.github.com/benmiroglio/39eb20e92a6fb0ad8055284009b2cd0c> that
we aren't blowing up telemetry ping sizes yet by sending native stack
traces for BHR hangs, and as a result we can now capture a deeper call
stack depth <https://bugzilla.mozilla.org/show_bug.cgi?id=1365749>, which
means the resulting data will be easier to analyze. Doug Thayer has also
been hard at work <https://bugzilla.mozilla.org/show_bug.cgi?id=1344003> at
creating a new BHR dashboard based on the perf-html UI. You can see a
sneak peak here <https://squarewave.github.io/?thread=0>, but do note that
this is work in progress! The raw BHR data
<https://s3-us-west-2.amazonaws.com/bhr-data/index.html> is still available
for your inspection.

Kannan Vijayan has been working on adding some low level instrumentation
<https://bugzilla.mozilla.org/show_bug.cgi?id=1357180> to SpiderMonkey in
order to get some detailed information on the relative runtime costs of
various builtin intrinsic operations inside the JS engine in various
workloads using the rdtsc instruction on Windows. He now has a working
setup that allows him to take a real world JS workload and get some
detailed data on what builtin intrinsics were the most costly in that
workload. This is extremely valuable because it allows us to focus our
optimization efforts on these builtins where the most gains are to be
achieved first. He already has some initial results
<https://bugzilla.mozilla.org/show_bug.cgi?id=1365361> of running this tool
on the Speedometer benchmark and on a general browsing workload and some
optimization work has already started
<https://bugzilla.mozilla.org/show_bug.cgi?id=1365650> to happen
<https://bugzilla.mozilla.org/show_bug.cgi?id=1365387>.

Dominik Strohmeier has been helping with running startup measurements
<https://docs.google.com/spreadsheets/d/1avx44MnGyzW4kj2Z_lbEwGAcxvn_jDtd3_CYtPo86T8/edit#gid=378417798>
on the reference Acer machine to track the progress of the ongoing startup
improvements using an HDMI video capture card. For these measurements, we
are tracking two numbers, one is the first paint times (the time at which
we paint the first frame from the browser window) and the other is the hero
element time (the time at which we paint the "hero element" which is the
search box in about:home in this case.) The baseline build here is the
Nightly of Apr 1st as a date before active work on startup optimizations
started. At that time, our median first paint time was 1232.84ms (with a
standard deviation of 16.58ms) and our hero element time was
1849.26ms (with a standard deviation of 28.58ms). On the Nightly of May
18, our first paint time is 849.66ms (with a standard deviation of 11.78ms)
and our hero element time is 1616.02ms (with a standard deviation of
24.59ms).

Next week we're going to have a small work week with some people from the
DOM, JS, Layout, Graphics and Perf teams here in Toronto. I expect to be
fully busy at the work week, so you should expect the next issue of this
newsletter in two weeks! With that, it is time to acknowledge the hard
work of those who helped make Firefox faster this past week. I hope I'm
not dropping any names by accident!

- Olli Pettay wrote a patch to have us coalesce scroll wheel events more
aggressively <https://bugzilla.mozilla.org/show_bug.cgi?id=1364018>, in
the hopes of improving scrolling performance on (at least) Google
Spreadsheets
- Dão Gottwald got rid of some nasty layout flushes in our tab strip code
<https://bugzilla.mozilla.org/show_bug.cgi?id=1364661> when adding and
removing tabs
- Kris Maglione made the content process also use the script precompiler
in order to speed up the startup by compiling scripts on a background thread
<https://bugzilla.mozilla.org/show_bug.cgi?id=1361900>. This resulted
in some decent improvements
<https://treeherder.mozilla.org/perf.html#/alerts?id=6623> in Talos
sessionrestore tests.
- Kris also got rid of some directory scans that the Add-ons Manager was
doing on start-up <https://bugzilla.mozilla.org/show_bug.cgi?id=1356826>,
which should result in improved start-up times.
- Mike Conley suppressed the window opening animation for the first
window <https://bugzilla.mozilla.org/show_bug.cgi?id=1362103>, buying us
some more time during startup (about 270ms on the reference hardware
<https://docs.google.com/spreadsheets/d/1avx44MnGyzW4kj2Z_lbEwGAcxvn_jDtd3_CYtPo86T8/edit#gid=2097068375>
!)
- Florian Quèze switched many uses of Task.jsm / yield to async
functions / await instead
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353542>, which allows us
to avoid cross-compartment wrapper overhead in certain situations. This was
a huge undertaking - big kudos to Florian!
- Dave Townsend lazified loading of the certificate database in the
add-on manager <https://bugzilla.mozilla.org/show_bug.cgi?id=1362364>.
- Patrick McManus made it so that POST’ing files with an async XHR no
longer does main thread IO
<https://bugzilla.mozilla.org/show_bug.cgi?id=1362388>.
- Botond Ballo made starting dragging the scrollbar be asynchronous when
using APZ even if the main thread of the content process is janking
<https://bugzilla.mozilla.org/show_bug.cgi?id=1349750>. This will
ensure that users who use the mouse to drag the scrollbar in order to
scroll web pages will get a smooth scrolling experience no matter how busy
the content process is. He also sped up painting on particularly complex
pages with many hit regions
<https://bugzilla.mozilla.org/show_bug.cgi?id=1363423>.
- Thomas Nguyen removed another sync reflow
<https://bugzilla.mozilla.org/show_bug.cgi?id=1356763> when opening the
AwesomeBar panel in some cases
- Ben Kelly made us choose whether to run multiple consecutive timeouts
in one shot of the event loop based on a time budget of 4ms
<https://bugzilla.mozilla.org/show_bug.cgi?id=1343912> rather than a
fixed maximum number of timeouts.
- Edouard Oger delayed the initialization of the Weave service
<https://bugzilla.mozilla.org/show_bug.cgi?id=1364571> until after the
first browser window has finished loading, which should improve start-up
time.
- Thomas Nguyen avoided a synchronous layout flush which would happen
when the awesomebar popup was either not displaying or already showing the
maximum number of results
<https://bugzilla.mozilla.org/show_bug.cgi?id=1356763>.
- Valentin Gosu made us dispatch an asynchronous job to check for
captive portals when a network connection becomes available
<https://bugzilla.mozilla.org/show_bug.cgi?id=1360328>.
- Michael Layzell added information about whether a hang reported to BHR
was observed when the user was interacting with the browser
<https://bugzilla.mozilla.org/show_bug.cgi?id=1353440>.
- Andreas Farre added telemetry about the average load caused by
timeouts in foreground and background tabs
<https://bugzilla.mozilla.org/show_bug.cgi?id=1355480>.
- André Bargull optimized Function.prototype.bind()
<https://bugzilla.mozilla.org/show_bug.cgi?id=1365387>.
- Mathieu Leplatre made the blocklist updater module load more lazily
<https://bugzilla.mozilla.org/show_bug.cgi?id=1357116>, which should
help to avoid some random UI jank.
- Doug Thayer built a visualization tool for BHR stacks
<https://squarewave.github.io/?thread=0> that borrows heavily from
perf.html! Source code is here.
<https://github.com/squarewave/hangs.html>
- Chris AtLee disabled omni.ja compression
<https://bugzilla.mozilla.org/show_bug.cgi?id=1362377> which,
unintuitively, resulted in a smaller download for users and faster start-up
time.
- William Chen made us reuse StackNodes in TreeBuilder
<https://bugzilla.mozilla.org/show_bug.cgi?id=1355441> in order to avoid
memory allocation overhead.
- Chris Pearce moved telemetry collection about which media decoders are
present to happen when the user is idle
<https://bugzilla.mozilla.org/show_bug.cgi?id=1362212>. Background hang
reports evidence had shown that some users would experience hangs of 8
seconds or more when this would run previously shortly after opening the
first browser window.
- Daniel Holbert made us react to some CSS overflow changes on body/html
elements without reframing the entire document
<https://bugzilla.mozilla.org/show_bug.cgi?id=1344398>.

Until next time, happy hacking!

Cheers,
--
Ehsan