Firefox Performance/Snappy Work Week: Warsaw edition

Last week I was with the “Snappy” team in Warsaw, Poland working out of the Noa Cowork space.

While there I got to meet more people that I have talked with online before and build stronger relationships. I also learnt a lot from Bas Schouten and Benoit Girard as they showed me the tools that they have been working on recently.

Bas works from Holland and is on the Graphics team. Firefox’ tab strip and toolbar area is one of our biggest areas of concern when it comes to snappiness. It is probably the most visible part of the browser that users attribute to responsiveness. Users may blame slow webpages on the website authors, but slow browser chrome will most definitely be blamed on Firefox itself.

Bas wrote a tool that records all of the drawing commands that the graphics system performs. These commands are then saved out to a file and his program can replay them step-by-step. This tool is really great at finding problematic drawing sequences.

In a couple cases, Firefox reaches near completion of drawing the navigation toolbar, and then decides to start the process over. One metric showed there were around 95% redundant drawing commands due to issues like this. While this tool is great at finding these issues, it’s not perfect. There is still a lot of work to do to find the relationship between our CSS, markup, and graphics system to determine which area is causing the issues and how we can fix them.

It should be noted the 95% redundancies seen is partially due to some aspects of the way we are currently using the drawing architecture. It does not mean 95% of performance is wasted. The practical speedup that could be achieved by removing redundancy is estimated to be between 10-20%. Further improvements can be achieved though by optimizing the actual drawing sequences. – Bas Schouten

I spent Monday and Tuesday working with Bas’ tool trying to fix some of the invalidation bugs that we were seeing. After I had one of the patches ready for review, we found that the invalidation issues were the cause of another bug and was only reproducible if the user had enabled an off-by-default preference.  While my bug fix was void, the knowledge gained was very valuable. Tim Taubert was able to work around the root cause of the invalidation issue and fix the browser.newtab.preload implementation to remove the extra invalidations.

I’m really happy to see this tool though, as issues like these could never be discovered without it.

Benoit works from Toronto and is also on the Graphics team. Benoit picked up a side project to implement a native profiler in to Firefox. This profiler is used to find areas of jank within the browser. Getting a profile of the browser is only a click away when the browser becomes unresponsive. These profiles greatly help Firefox developers fix these responsiveness issues.

To use the Gecko Profiler you will need to run a Nightly build of the browser and install the Gecko Profiler add-on. The add-on installs itself in to the Add-On Bar at the bottom of the browser. Pressing Ctrl+Shift+O will show the current profile.

I spent the second part of the week working on fixing one of the issues that the profiler found. The code for highlighting the base domain in Firefox contained some inefficient regular expressions and  I was able to replace them with simple string manipulation. This improvement sped up the function by ~40%.

Overall I think the Snappy work week was really productive. It’s really nice to get people from various teams in the same room for a week since the barrier to communication is much lower. Weeks like these are even more valuable as a way to get to know your coworkers since IRC and Bugzilla aren’t perfect ways to express your thoughts.

Update (24 Sept): I included a clarification from Bas on the 95% redundancy remark.