Firefox Startup Performance

A team of Firefox developers and others are working on making Firefox startup faster. Per Mike Beltzner’s post, we’ll be updating our status weekly. Here’s the status of what the team did this week, as well as pointers to some other work going on. The list here highlights major points, but is not complete. Many more details of these projects, as well as other areas for investigation can be found on the wiki page, and on Vlad and Taras’ blogs.

Status

  • XPCOM component combining (Dietrich): Manually combined a bunch of files, and found improvements in sub 100ms, but varying results, so going to check-in to the Places branch temporarily to get better numbers. Writing a script to hook into the build system to knit the components together automatically, but need better numbers before going further.
  • Enabling PGO for SQLite, mozStorage and Places (Dietrich): Made a patch to re-enable PGO for these, and checked into the Places branch. Currently there are unit tests failing, but they look unrelated. Need to trigger more runs to ensure that’s the case. Performance numbers are not definitive, need more runs to complete.
  • Dead code hunting with JSHydra (DDahl): Have basic code for function finding, making progress on code for building JS context for chrome URIs. (props for help from taras, humph, jcranmer in #static)
  • Combining XPT files on Mac (Drew): Potentially significant gain of a few seconds on startup, investigation continuing.
  • Startup Timeline (Vlad, DDahl): This is still in review.
  • Combining jar files (Taras): This is ready to check-in (again).

Next Steps

  • Confirm numbers for combining JS components, finish script to automate combining, work with Ted to hook it into the packaging process, see if any modules can be combined.
  • Find out why tests are failing for PGO and quantify gain/loss when the slow tinderboxen finally report some numbers.
  • Get the startup timeline reviewed, landed and start adding markers and performing analysis.
  • Investigate why wall-clock time of combined jars doesn’t decrease.
  • Get full browser JS context working in JSHydra, write the uncalled-function script, file dead-code bugs, get it plugged into continuous integration on tinderbox.
  • Get bug 475289 and bug 499123 landed, further reducing IO and component registration time spent at startup.

One Comment on “Firefox Startup Performance”

  1. B.J. Herbison says:

    Have you considered adding a splash screen? It doesn’t make Firefox start faster, but lets the user know it is trying to start.

    I’ve seen people end up with up to four Firefox windows after they kept clicking because they weren’t sure it was started.

    Every human factors expert I’ve talk to or read says “make sure the user gets a response to actions”. Unfortunately, arguing for good human interaction has not historically been well received by the Firefox team: https://bugzilla.mozilla.org/show_bug.cgi?id=198605


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s