Keeping track of ongoing progress and how much more work different areas need is important. I've found the new Firefox Health Dashboards that Harald Kirschner and the team have worked on extremely helpful. You can see the status of the ongoing work on the various areas on the Quantum project there, including the Quantum Flow project. The other charts that I've been watching are the Speedometer v2 benchmark charts (32-bit and 64-bit Windows).
Ehsan Akhgari is a programmer living in Toronto working for Mozilla. He has over 10 years of experience on browsers and the web platform and Firefox. Learn more about him here.
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 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, which means the resulting data will be easier to analyze. Doug Thayer has also been hard at work at creating a new BHR dashboard based on the perf-html UI.
It's been 10 weeks since I have started writing these newsletters (the number in the title isn't an off by one error, there was a one week hiatus due to a work week!). We still have quite a bit of work ahead of us, but we have also accomplished a good amount. Finding a good metric for progress is hard, but we live and breathe in Bugzilla, so we use a bug-based burn-down chart.
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 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.
I would like to share some updates about some of the ongoing performance related work. We have started looking at the native stack traces that are submitted through telemetry from the Background Hang Reports that take more than 8 seconds. (We were hoping to have been able to reduce this threshold to 256ms for a while now, but the road has been bumpy – but this should land really soon now!