Quantum Flow Engineering Newsletter #24 – Ehsan Akhgari
source link: https://ehsanakhgari.org/blog/2017-09-15/quantum-flow-engineering-newsletter-24
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Quantum Flow Engineering Newsletter #24
I hope you're not tired of reading these newsletters so far. If not, I applaud your patience with me in the past few months. But next week, as Firefox 57 will merge to the Beta channel, I'm planning to write the last one of this series.
Nightly has been pretty solid on performance. It is prudent at this point to focus our attention more on other aspects of quality for the 57 release, to make sure that things like the crash rate and regressions are under control. The triage process that we set up in March to enable everyone to take part in finding and nominating performance problems which they think should be fixed in Firefox 57 was started with the goal of creating a large pool of prioritized bugs that we believed would vastly impact the real world performance of Firefox for the majority of our users. I think this process worked quite well overall, but it has mostly served its purpose, and participating in the triage takes a lot of time (we sometimes had two meetings per week to be able to deal with the incoming volume of bugs!) With one week left, it seemed like a good decision to stop the triage meetings now. We also had a weekly 30-minute standup meeting where people talked about what they had done on Quantum Flow during the past week (and you read about many of those in the newsletters!), and for similar reasons that meeting also will be wound down. This gives back several person-hours back on their calendars to people who really need it, hurray!
The work on the Speedometer benchmark for 57 is more or less wrapped up at this point. One noteworthy change that happened last week which I should mention here is this jump in the numbers which happened on September 7. The reason behind it was a change on the benchmark side to switch from reporting the score using arithmetic mean to using geometric mean. This is a good change in my opinion because it means that the impact of a few of the JS frameworks being tested wouldn't dominate the overall score. The unfortunate news is that as a result of this change, Firefox took a bigger hit in numbers than Chrome did, but I'm still very proud of all the great work that happened when optimizing for this benchmark, and I think the right response to this change is for us to optimize more to get the few percentages of head-to-head comparison that we lost back. :-)
Even though most of the planned performance work for Firefox 57 is done, it doesn't mean that people are done pouring in their great fixes as things are making it to the finish line last-minute! So now please allow me to take a moment to thank everyone who helped make Firefox faster in the last week, as usual, I hope I'm not forgetting any names here:
- Marco Bonardo improved the performance of the bookmarks toolbar when it has a large number of bookmarks by only dealing with the few bookmarks that would be visible on the toolbar in the code.
- Will Wang moved the Windows jump lists updater code to the idle queue. He also moved the sessionstore data collector code in the content process to the idle queue.
- André Bargull made IsRegExpObject and RegExpInstanceOptimizable inlined in the JIT code. He also removed some unnecessary rooting in intrinsic_IsConstructor.
- Kirk Steuber made it so that we try to call ::RegisterDragDrop during idle time which makes it more likely that a DLL will be preloaded off of the main thread, which should improve start-up performance in some cases.
- Perry Jiang got rid of the contextmenu sync IPC message
- Adam Gashlin made it so that we cache OS theme margins on Windows
- Robert Strong made it so that we avoid main thread IO after first run after an update is applied, and when an update is downloaded. This should help improve performance for our Nightly users in particular, since they get updates very often.
- Andrew McCreight landed the code that allows all JSM’s to share the same compartment. There are general performance and memory benefits to doing this. This is landing disabled by default, and the bug to enable it is here.
- Kris Maglione sped up some of the MessageChannel.jsm code involved in the webRequest API, among other things. He also ensured that the JSM script precompiler compiles scripts into the shared JSM global mentioned above to save the cost of cloning them into the destination global before execution. Kris also removed the add-on SDK from Firefox. The code inside the add-on SDK was used by some legacy extensions and various internal browser components and was the source of many performance issues, and removing it was the last measure to make sure that such issues would never rise again in the future.
- Botond Ballo enabled asynchronous scrolling when the scrollbar thumb is dragged using touch input.
- Olli Pettay removed a GC trigger every time Gecko finished executing some JavaScript. This was an old trick devised to satisfy benchmarks but he came up with a better fix for that last week.
- Jon Coppeard changed JavaScript Map and Set objects and their iterators to be allocated from the nursery to benefit from incremental garbage collection.
- Mason Chang and Bas Schouten enabled specifying a limit on the blend surface area and the portion of the layer being resolved for D2D draw targets.
- Andrea Marchesini avoided doing main-thread I/O when reading the contents of files read under some situations for some Web APIs that access files. One example is a file selected using an input element which is read using a FileReader.
- Mats Palmgren optimized away a lot of the virtual calls to QueryFrame through do_QueryFrame().
- Emilio Cobos Álvarez avoided flushing frames in nsHideViewer when we know a new frame won’t be constructed. This sped up loading new results on Twitter under some circumstances dramatically.
Recommend
-
157
Quantum Flow Engineering Newsletter #2521 Sep 2017 about 1700 words 8 minute read The Quantum Flow project started as a cross-functional effort to study and fix the most serious performance issues of F...
-
200
WebRender newsletter #8 Nical
-
155
Another late newsletter as I was side-tracked by conference travel, followed by a holiday and then a training. My apologies. Brace yourselves though, there has been a lot of good stuff landing in WebRender and Gecko during that time. Enabling We...
-
97
Another long overdue newsletter is here (I still consistently underestimate the time it takes to gather information and write these up, oops!). I have been using Firefox with WebRender enabled as my main browser for a little while now on various...
-
109
Newsletter #11 is finally here, even later than usual due to an intense week in Austin where all of Mozilla's staff and a few independent contributors gathered, followed by yours truly taking two weeks off. Our focus before the Austin allhands w...
-
119
Hi there, your 12th WebRender newsletter has arrived. As I mentioned in the previous newsletter, the biggest theme in the last two weeks has been fixing correctness bugs and adding missing features. I keep learning new and scary things about tex...
-
112
Greetings! Time for issue #13 of your favorite newsletter, where you can follow the progress of WebRender and its integration in Gecko. We are still busy fixing correctness issues (as you can see by the number of times the word "fixed" appears i...
-
119
Your favorite WebRender newsletter is ready. TL;DR: "fixed [...], fixed [...], fixed [...], Glenn makes things even faster, fixed [...], ad-lib". Still mostly focusing on conformance and stability, although there is some performance work in prog...
-
88
I was in Toronto (where a large part of the gfx team is) last week and we used this time to make plans on various unresolved questions regarding WebRender in Gecko. One of them is how to integrate APZ with the asynchronous scene building infrast...
-
85
Greetings! 16th newsletter inbound, with some exciting fixes. Oh yeah, fixes again and again, and spoiler alert: this will remain the main topic for a little while. So what's exciting about it this time around? For one, Heftig, Martin Stránský a...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK