3 February, 2012 § 5 Comments
This past week I’ve been in Brussels, Belgium with about 15 people from Mozilla’s performance and front-end teams. This week we focused on what improvements we could make to the Mozilla platform and Firefox.
On Monday and Tuesday we were located at HSBXL, a hackerspace in central Brussels. While at HSBXL, people from the two teams did demos on tools that we can use to measure the performance of Firefox:
- Felipe (@felipc) demoed the Simple Profiler System that landed in Firefox 11.
- David Teller (@imyoric) demoed how to use xperf for tracking main-thread I/O.
- Dietrich (@dietrich) introduced the team to Peptest, an “automated testing framework designed to test whether or not the browser’s UI thread remains responsive while performing a variety of actions”.
- Taras (@tarasglek) demoed about:jank, an early-stage add-on that shows how often certain predetermined places within the codebase have been reached.
- I (@weinjared) demoed how to make bullet-time screen captures of Firefox and paint flashing.
Wednesday through Friday we went to another side of town to visit the BetaGroup coworking space. Our first topic upon arrival was a telemetry-athon that Dietrich setup to get together a list of telemetry probes that we could build into Firefox. Telemetry is another tool that we use to measure the responsiveness of various parts of Firefox.
Felipe and Marco started looking into switching-tabs telemetry, and have put together an experimental patch to check the results. They will need some deeper checks at the platform level to proceed with this work. Felipe also has been writing some telemetry stopwatch helper modules.
Dietrich spend some time implementing session restore telemetry, as well as making session restore periodic updates work asynchronously.
Neil worked on adding telemetry for measuring the time it takes for new windows to open.
Paolo worked on adding telemetry metrics for private browsing transitions. It looks like this work is stalled while we figure out the status of work being done by an academic group.
I landed telemetry probes that measure how long it takes for the site-identity popup and the Firefox menu to appear.
Marco figured out two possible causes for recent UI hangs due to thread contention. A fix, authored by Paolo Amadini, for one of the causes is on its way to landing and work on the other one is starting. Marco checked some queries possibly causing thread contention with Vlad Djeric.
On the topic of DOM Storage, we had a great talk about reducing I/O and making it asynchronous. Tim (@ttaubert) is looking in to changing the way that we store the data so it will have faster read and write times.
Paolo and Marco discussed converting the favicons API to use asynchronous methods.
A lot of work got done while we were in Brussels, and the team got to talk in person with each other which isn’t always so easy to do. I was very happy to get to meet Paolo for the first time, as he has been working on the new Download Manager for Firefox and a person I’ve been in contact with but never seen him before.
1 February, 2012 § 26 Comments
Writing efficient and responsive websites are important to providing a great user experience. Some website layouts cause inefficient rendering, hurting the experience of the users that we try so hard to please.
Starting in Firefox 11 (currently in the beta channel), there is a hidden preference (nglayout.debug.paint_flashing) to enable what we call “paint flashing”.
Whenever the layout engine determines that a region of the browser requires repainting, the region is tinted with a random color value. Regions experiencing heavy paint flashing can turn your browser in to a fun rave, but also show web developers (and browser developers too!) areas of the code that aren’t being as optimal as possible.
For example, there is currently a bug on file for Firefox where the HTML5 video controls cause unnecessary paint flashing (bug 722261). Modifying the markup for the controls can fix this and improve the performance of the controls. Paint flashing was required to find this inefficiency, and it will also be the tool that we will thank for finding many other inefficiencies as we move forward.
To enable this feature in Firefox, go to about:config and create a new Boolean preference with the name of nglayout.debug.paint_flashing and set the preference to true.
17 December, 2011 § 6 Comments
Felix Fung once said something along the lines that main-thread IO should only be dealt with by tossing it in to a woodchipper, making mushroom fricassee with it, microwaving it, and then butchering it up some more.
Today marked the completion of Felix’s internship at Mozilla. While sad to see him go, I’m happy to say that Felix did an amazing job at removing some of the main-thread IO found in Firefox, thus making Firefox even faster.
For example, in Firefox Aurora (soon to be Firefox 10), downloads in the browser now use considerably less CPU usage (sometimes reduced by ~50%).
Another great fix came in for
about:permissions. Users who had many thousands of sites listed in
about:permissions would encounter sluggish behavior from the browser when loading
about:permissions. This sluggish-ness is now a thing of the past that should be long forgotten and never missed.
In Firefox Nightly (soon to be Firefox 11), we now have a complete internal asynchronous API for favicons. Work had started on this in earlier releases, but it has now reached completion. The landing of this feature will allow consumers of favicons (think of: tabs, history, bookmarks, downloads, Windows 7 jump lists, I-don’t-know-what-else-but-there-are-probably-tons-more, etc) to render, react, and update much quicker.
Felix (wearing the plum dress shirt) wasn’t the only intern in Mountain View during the Fall. See the picture to the right for a group of smart, funny, and hard-working interns who have been working to make the internet better for all.