Firefox Performance Update

I’ve been focusing more on Jetpack development this quarter, but will still be posting performance round-ups regularly here. In fact, here’s one now:

  • Taras Glek continues to blog his progress on improving the binaries we ship, talking about how reordering binaries improves memory use as well as load time, leveraging GCC’s PGO for fast startup, and finally about Icegrind, his Valgrind plugin that generates a log of the order of access to mmap’d files.
  • Are we fast yet?! The answer to that question, at least in regards to JavaScript performance test suites, can be found at AreWeFastYet.com, where you’ll see graphs that show Firefox trunk’s performance relative to Google’s V8 and Apple’s Nitro on the Sunspider and V8Bench tests. I won’t spoil the answer for you, you’ll have to go check it out for yourself.
  • I finished and checked-in my changes to the Tinderbox Pushlog, adding a new feature that provides at-a-glance comparison in performance test results between any two pushes on the page (screenshot). It will go live next time Marcus pushes changes out to his server. But he’s not online at the moment, so I don’t know when this feature will go live. Heh, it went live moments after I published this post.
  • Heather Arthur and Clint Talbert are working on a project to add performance data to Addons.mozilla.org for extensions. They’re starting with the effect of a given extension on Firefox startup time. Follow along on the bug, or watch project Dirty Harry on Github.
  • Improving the AMO extension validator: AMO scans uploaded extensions and reports problems to the authors. For performance best-practices, we should at least warn the authors if possible if their add-on is doing something that’ll make Firefox slow. This bug is for warning about add-ons that don’t have their content in a JAR file. If you see any thing in the best practices guide that can be statically detected, please file a bug for it here.

If you have any other performance-related bugs, blog posts, anecdotes or other tomfoolery, post it in the comments!


Firefox Performance Update

As I mentioned in my previous update, the scope of these updates has expanded beyond start-up time. That said, I can’t keep track of everything! So if you have an update, email it to me if you want it in the post, or just add it in the comments.

  • First, I just have to say that Marco’s fix for bug 542943 has changed the way I think about browser restarts, removing the fear entirely. It turns out that, for me anyway, the majority of the slowness involved in restarting was waiting for the process to exit. After Marco’s landing, it’s nearly instantaneous.
  • While I was away, Taras blogged nearly daily about his findings while working on Linux code locality. He first posted a graph of I/O from library loading, then a long post about why library loading sucks on Linux, followed by some findings regarding madvise and prelink, finally posting about linker inefficiencies and SuSE’s workaround.
  • Mike Wu and others are moving forward on the “omnijar” project, which moves most of the core application files into a single JAR file. Taras described it as “extreme filesystem makeover”, and found ~10% start-up improvement with this approach on the desktop.
  • Clint Talbert and Heather Arthur are beginning work on a project that measures add-on performance, that will hook into AMO to show developers how their add-ons perform.
  • Drew Willcoxon got r+ on bug 536893 to allow asynchronous opening of Places query results. Once we start using the feature, expect bookmark and history UI to get snappier!
  • Taras got review on bug 516085, which consolidates access to core services that currently accessed hundreds of thousands of times during a browsing session.
  • A bunch of people have added tips to the add-on performance “best practices” document. I’ll be cleaning it up and moving it to MDC soon.
  • While the tinderbox pushlog is fantastic for viewing per-checkin results, and a broader view of tree activity, it doesn’t provide any facility for comparing the results of performance tests between landings. So I spent some time this week writing an addition that allows you to select any two pushes, and view a comparison table showing the difference in performance across all tests on all operating systems for those revisions. I’ll clean it up, and try to get it deployed, but regardless will make it available as a Jetpack or Greasemonkey script sometime next week.

For more info:

  • Startup performance activity is tracked here.
  • Add-on performance efforts are being tracked on this page.
  • Weekly performance results for all measurements are available on the snapshot, and trends available on the dashboard.

Firefox Performance Report, Startup and Otherwise – March 19, 2010

A couple of notices: First, I’m going to start including various performance-related items in these posts that aren’t purely about startup time. There’s a whole bunch of activity happening that isn’t really rolled up anywhere, so it might as well be here. Second, I’ll be out on vacation in Florida next week, so there will not be a status update.

  • Last week I forgot to add that Marco Bonardo landed bug 542943, which removed a hash of all bookmarks that stayed resident for the lifetime of the application. This resulted in a 97% improvement in shutdown time for our test of a very large bookmarks+history collection.
  • Ted’s taken over the static build project, and has new patches up.
  • Taras is working on Linux code locality via a Valgrind plugin he’s writing, with help from those folks.
  • At the platform work week Taras talked to Ehsan, who it turns out had a bunch of ideas for improving startup there. I’ve filed bugs from Ehsan’s notes for better Windows code locality, binding DLL function addresses to the executable, DLL rebasing, and DLL lazy-loading.
  • The add-on performance “best practices” document is getting bigger and better. If you have ideas for improving add-on performance, please add them to the doc!
  • All of our add-on performance efforts are being tracked centrally on this page. If you want to get involved, hop on one of those bugs. If you want to stay updated, “watch” that page and you’ll get emails whenever it’s updated.
  • I’ve updated the main Performance wiki page. The top sections are now up to date. Next I’ll be updating the testing and reference sections, and breaking out the task-specific content and moving it to an updated table of performance activities, like we currently have for startup, addons, etc. When the page is more manageable, I’ll remove the TOC that’s pushing everything below the fold.
  • As usual, the table of active startup performance activity is here.

Firefox Startup Performance March 12, 2010

No update on the ongoing code projects this week. However, we investigated the extension performance work I mentioned last week, and got a conversation going, with posts by Taras, Asa and myself. I’ve listed the various ideas and approaches that came out of those posts and comments here.


Firefox Startup Performance – March 5, 2010

I spent the week on-site at Mozilla HQ in Mountain View, which was great.


Firefox Startup Performance – Stardate 2.27.2010

Instead of copying around the table of high-priority startup projects, it’s now centrally located and updated on the Startup wiki page. A couple of front-end optimizations landed this week:

  • Neil landed bug 354048 to not rebuild toolbars at startup.
  • Ryan landed bug 522842 for the search service to not send notifications until all engines are loaded.

I’ll be in Mountain View all next week for the Firefox work-week.


Firefox Startup Performance – Feb 19, 2010

Taras blogged about the function ordering work he did while on vacation in Fiji (?!). Looks like the potential for a minimum 10% win there, very exciting. Follow along in bug 531406.

Other than that, no major updates:

  • Zack found surprisingly large performance wins just from deCOMtamination patches in his CSS work. If you want to help out, bug 105431 is the deCOM tracker bug, and bug 545052 is about building tools for automating deCOMtamination.
  • Static build: Still in reviews, need to figure out approach to binary tests on the tinderbox.
  • Ben’s fastload cache replacement is still waiting on first-review from Ben Smedberg.
  • Bug 354048 to not rebuild toolbars at startup, still cycling through reviews.

Firefox Startup Performance – Feb 11, 2010

Various minor updates this week:

  • Static build: Ted did the first pass of review. Getting close. Will land on the Places branch once binary tests build, to see perf impact.
  • Ben’s fastload cache replacement is still waiting on first-review from Ben Smedberg.
  • Neil took up bug 354048 to not rebuild toolbars at startup, should reduce the DOM activity some at least. The patch is in review by Dao and Mano.
  • Marco has nearly completed bug 542943, removing the bookmark redirect hash, which means less SQL at startup and less memory usage by the bookmarks service.
  • I put a patch up on bug 545516 that fixes some bugs and cleans up the layout of the Performance Snapshot. Will get it landed next week.
  • Started working with John O’Duinn and Mike Morgan to get a team together to work on the graph server.

Firefox Startup Performance – Feb 5, 2010

Nothing major to report. Some of the big projects are in the final stretch, which is great to see.

  • Static build: Joel’s in cleanup phase, making sure the mobile tinderboxes build with the changes. Core patch is waiting on first review from Ted.
  • Ben’s fastload cache replacement is waiting on first-review from Ben Smedberg.
  • Zach has more data on the effect of the CSS parser optimizations he’s been working on.
  • Asaf put up an experimental patch for making the bookmarks toolbar all JS, no XBL.

Related work I did this week:

  • Started updating the Performance Snapshot. Fixing a couple of bugs and making the percentages relative to the 3.6 branch.
  • Spent some time poking at the graph server. It’s got serious performance problems, and is lacking a few features that’d make it immensely useful, instead of only somewhat useful. It just needs a little love, that’s all.
  • Landed bug 506471, moving FUEL out of the startup path.

Firefox Startup Performance – January 29

No big changes from last week, so I’m not going to knock you over the head with the big table, but here are some notes on the progress of some of the projects and areas of research:

  • Joel has patch in Ted’s review queue for the static build changes. He’s also working on getting Windows builds un-broken, with help from Ben Smedberg and Brad Lassey.
  • Rob Campbell enabled PGO on the Mac, and found no detectable difference in performance. I built PGO on Linux, and found the same. It could be that there’s no improvement to be had. It could be that our profile-generation approach doesn’t target the codepaths that our performance tests measure. Not sure yet!
  • I talked with Rob Stong about the fast-startup component, and he brought up a bunch of problems with enabling it in multi-user environments. I’m pretty convinced that there’s no way we can ship with it enabled. And I’m still convinced that it should be exposed as an option to users. I did get it actually working on Windows 7, and as expected, first startup post boot was 60% faster. The scary part is that it took 40% of startup to do the rest…
  • I researched code locality options for Linux, and haven’t yet found a way to specify a function order like you’re able to on Darwin. Joel’s been spending some time looking into this on Mac, but gprof is broken on Snow Leopard – instrumented builds just hang. Boo.
  • Joel talked with some Apple developers on the Darwin list and got some more information about compressing with HFS+. They thought it was pretty hacky, recommended improving code locality instead (See previous comment about gprof being broken. *sigh*). Compressing locally does break our code-signed builds, so might not be feasible anyways. Next is to look into compressing on the release side.

Follow

Get every new post delivered to your Inbox.