Quantum Flow Engineering Newsletter #16

It has been almost a month and a half since the last time that I talked about our progress in fighting sync IPC issues.  So I figured it’s time to prepare another Sync IPC Analysis report.  Again, unfortunately only the latest data is available in the spreadsheet.  But here are screenshot of the C++ and JS IPC message pie charts:

As you can see, as we have made even more progress in fixing more sync IPC issues, now the document.cookie issue is even a larger relative share of the pie, at 60%.  That is followed by some JS IPC, PAPZCTreeManager::Msg_ReceiveMouseInputEvent (which is a fast sync IPC message used by the async pan zoom component which would be hard to replace), followed by more JS IPC, followed by PContent::Msg_GetBlocklistState which is recently fixed, followed by PBrowser::Msg_NotifyIMEFocus, followed by more JS IPC and CPOW overhead before we get to the longer tail.  If you look at the JS sync IPC chart, you will see that almost all the overhead there is due to add-ons.  Hopefully none of this will be an issue after Firefox 57 with the new out of process WebExtensions for Windows users.  The only message in this chart stemming from our code that shows up in the data is contextmenu.

The rate of progress here has been really great to see, and this is thanks to the hard work of many people across many different teams.  Some of these issues have required heroic efforts to fix, and it’s really great to see this much progress made in so little time.

The development of Firefox 56 in coming to a close rapidly.  Firefox 57 branches off on Aug 2, and we have about 9 weeks from now until Firefox 57 rides the trains to beta.  So far, according to our burn-down chart, we have closed around 224 [qf:p1] bugs and have yet 110 more to fix.  Fortunately Quantum Flow is not one of those projects that needs all of those bugs to be fixed, because we may not end up having enough time to fix these bugs for the final release, especially since we usually keep adding new bugs to the list in our weekly triage sessions.  Soon we will probably need to reassess the priority of some of these bugs as the eventual deadline approaches.

It is now time for me to acknowledge the great work of everyone who helped by contributing performance improvements over the past two weeks.  As usual, I hope I’m not forgetting any names!

Posted in Blog Tagged with: , ,
6 comments on “Quantum Flow Engineering Newsletter #16
  1. sciguyryan says:

    Thanks for the update. It’s inspiring to see just how quickly these issues can be burned away.

    As a nightly build user I can say that I’ve seen a huge performance improvement over the last few months. I installed 55 a few weeks back to see just how fast things were and it’s really impressive.

    I’ve also been playing around with Servo’s CSS engine and that also seems to provide a nice performance boost.

    Can’t wait to see much more of this in the upcoming months!

  2. klop*cz says:

    Thank you very much for the newsletter. It’s great to read it. Thumbs up.

  3. Mike S. says:

    Wow! I’m glad I found these newsletters. It’s neat to read the bits of project. Hooray (no snark intended or implied) to the Firefox team.

    I am using the EFF Privacy Badger add-on, so I presume the second improvement you list to handling extensions off the main thread will affect me (on Linux) later this year or early next year. Again I am excited, I don’t want to give up Privacy Badger but it does slow Firefox down.

    • ehsan says:

      Hmm, I just tested this, and the latest version of the EFF Privacy Badger add-on that you can install from https://www.eff.org/privacybadger is compatible with the latest add-on technologies, so later this year it will be moved out of process automatically and its performance will improve even further. But note that this is going to be completely invisible to the user (unless there are bugs, of course) and the goal is for you to be able to continue using Privacy Badger without it slowing Firefox down! That is what we’ll hopefully achieve in 57. 🙂

  4. This blog is very informative. Though over my head, I enjoy the sportscaster tone of “giving credit where credit is due” and quantifying how different changes affect performance.

    I have some simple questions that I simply cannot glean from anywhere.

    A few things:
    1, can there be some reference or follow-up to when a change lands in stable?

    2, can you highlight what can affect both Firefox on Linux and Firefox for Android?

    3, to what extent is Firefox for Android measured for telemetry as compared to desktop?

    I always wonder if and how long individual performance improvements might linger in nightlies and if they’re actively monitored to insure they do.

    Additionally, I wonder what gets to improve Linux and- more importantly to me- Firefox for Android.

    It’d be nice to find something that answers those nagging questions by someone who knows the significance of the code and the ins and outs of Bugzilla.

    • ehsan says:

      Sorry for the delay in responding. My blog software managed to not send any notifications about incoming comments!

      1. We use a pretty predictable release schedule, see https://wiki.mozilla.org/RapidRelease/Calendar. You can look at any date, under central would be the matching version of Firefox on Nightly (central refers to mozilla-central, our code repository name), and then look for that version and find the corresponding row under the release date column. (Sometimes release dates shift by a couple of days due to unforeseen issues but we are fairly consistent.)

      2. Most of our code is cross platform, so almost everything I mention affects all desktop OSes equally. When things are specific to Windows or Mac those are explicitly called out, but others should apply to Linux as well. Android is different than desktop in a few ways. First and most obviously the UI is different, so none of the fixes in the browser front-end apply to Android. Secondly the Android browser is currently single process so the fixes to the multi-process architecture of the browser (for example all of the sync IPC fixes I keep talking about) don’t matter to Android yet, until we port the Android browser to a multi-process architecture as well, which is planned to happen at some point. Also sometimes new projects don’t initially support it to keep the scope limited, for example Stylo, our new CSS engine written in Rust that we are sharing with Servo our experimental browser engine doesn’t support Android yet.

      3. When looking at telemetry data we usually look at the data from all platforms, but the details really depend on specifically what we want to measure. Unless data from mobile is actively misleading for some reason (for example because of introducing a large bias if the data is about network speeds which can be vastly different across desktop/mobile users). Usually when looking at telemetry data we’re trying to answer a specific question, so we think more in terms of the right pieces of the data for the purpose of the task at hand than a rigid set of specific platforms.

      Hope this is helpful.