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).

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.

It's time for another quick update about the recent Quantum Flow work. I want to start by shedding some light into the performance of synchronous IPC caused by JavaScript. Here is a breakdown report for data as of today similar to the previous ones. Let's look at the top 10 worst offenders: All of the ones with names starting with Addons: or Content: are e10s compatibility shims that we have been using to make non-e10s compatible add-ons work with Firefox.

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!