Firefox Performance/Snappy work week recap
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.
Telemetry probes
Marco (@mak77) worked on telemetry probes for: idle maintenance time; frecency update time; and bookmarks toolbar load time.
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.
Thread contention
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.
DOM Storage
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.
Other topics
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.
Nice to read responsiveness is getting serious attention. For me the number one thing that could be improved is the time between a click on a link, and the actual link handling (especially when just changing css with javascript after clicks). This currently is an obstacle in making webapps feel as native and responsive as desktop apps.
Is there any probe measuring link clicks to link handling?
Thanks for the suggestion Tim. I’m not aware of such a telemetry probe. I’ve filed a bug to add one though, so we can track this and see what improvements can be made (http://bugzil.la/725675).
Tnx msujaws!
The main point is that there is a very short, but noticeable delay between clicking a link and the action involved (for example a div sliding open). Chrome is much more responsive in this way.
ps. could you please remove my e-mail from that bugzilla description (or use the alias from this message?) 🙂 tnx!
Cool, it’d be great if you could add a good testcase to the bug to help explain the situation.
As for the email address, I’m sorry for including your email in the description. Unfortunately there isn’t a way to edit Bugzilla comments.
[…] have given talks at the Performance team work week in Brussels, Belgium, an Add-on SDK workshop at the Mozilla offices in Mountain View, CA, and two […]