Firefox Startup Performance – Dec 14

I’m going to be changing the format of these posts a bit, to put focus on the most important issues currently blocking a super-fast startup of Firefox. Hopefully it’ll bring attention on the longest-running, hardest-to-fix, but highest-impact bugs. Right now I’m defining high-impact as changes that bring a 10% or greater improvement. Some of these bugs we don’t yet have solid data on how much of an impact, but expect it to be filled in soon as we narrow the focus onto these. As always, the current numbers for startup and all other tests are available on the Performance Snapshot Page.

Top Startup Bugs

Estimated win Bug # Summary Owner Status Notes
>10% 512584 Super fast paths for Components.classes and Components.interfaces Taras Glek in progress Got consultation from mrbkap, needs new patch.
>10% 525013 Investigate a more static build configuration of Firefox Joel Reymont Mac and Linux in progress Only measured on Mac so far, need Linux numbers and someone to figure out the Windows story.
up to 25% 514083 Per-file HFS+ compression on Mac OSX 10.6 Joel Reymont in progress Snow Leopard only.
TBD 520309 Startup cache: replacement for fastload cache Ben Hsieh review More efficient than current fastload, and key to enabling fastloading of XBL, CSS, manifests and various other data. Need to push to Places branch to figure out base perf difference from current fastload.
TBD 503483 Turn on –enable-faststart for Firefox by default Dietrich needs testing Loads Firefox core libraries at boot time. Need to test on all OSes, publish the numbers, and get discussion going.
TBD 513149 Speed up CSS parsing by using a machine generated lexer Zack Weinberg Zack’s blocked on other work Taras says it’s high, but no figures, so need better data here.

Other activity this week:

  • Jonathan Kew landed bug 519445 on trunk, which improves font loading on Mac. The patch didn’t dent the Ts graph, as the test loads a basically empty page. This patch has the largest effect when pages load various fonts, and have a large font collection. For instance, here John Dagget comments that on a system with 2000+ fonts, the loading time of the font system went from 6 seconds down to 0.33 seconds.
  • Rob Strong blogged about time spent executing JS in the front-end, and put up a table of the worst offenders.
  • The measurements Rob made above are from an instrumentation effort that’s happening in bug 507012, that will give us great visibility into where time is spent in JS. You can do similar profiling using DTrace, but that’s Mac only, and requires separate tools and scripts to be installed. This instrumentation will eventually be available across platforms in release builds of Firefox. It’ll default to off, but be togglable via an environmental variable or some other method. Providing tools like this makes it *easy* for anyone working on Firefox to diagnose performance problems.

Projects in a holding pattern:

  • Ryan Flint has a WIP patch to minify JS on bug 524858 that significantly reduces the size of shipped JavaScript files.
  • JARification: David abandoned moving JS modules into a JAR file, since those files are fastloaded. However, since we want things like post-extension-install restarts to be fast, and those cause fastload cache invalidation, we might want to do things like this anyways. I filed a bug for the same treatment for components. These are lower priority, since they’re not the normal startup case. Follow along with all JAR-ification via the tracker bug.
  • Startup Timeline: No updates, still not landed. Add [ft] in the whiteboard of your bug w/ the function names you want timed and David will generate it and update the bug.
  • Static Analysis: No progress on bug 506128. David needs to file a bug with the final log of named-yet-uncalled functions.
  • Dirty Profile Testing: No progress. We have a list of test scenarios, still need to file bugs for each, generate Talos config patches and profile data, and then move it into Rel-Eng territory. Also, need to get a separate Tinderbox tree, since it’s going to cause a bazillion new columns.
  • Joel Reymont noted in bug 513076 that there are serious drawbacks to getting our libraries in the dyld shared cache on Mac, so has deprioritized that work.

As usual, more details and links are available on the project wiki, and we’re available to answer questions in #startup on

4 Comments on “Firefox Startup Performance – Dec 14”

  1. Zoog says:

    I am curious, do you have any rough estimates about how much improvement is actually possible? For example, is it unreasonable expecting the cold start time to be cut to 1/3 compared to Fx v3.5? Or having a cold start <= 15 s even on modest hardware (on my WinXP machine v3.5 starts up in ~45s for the first time, after Windows has quit the disk churning)?

    I know it's probably hard to judge this at this time. I was just wondering how clear a picture the developers have currently about the things that are slowing down cold startup, and what their opinions are about realistic possibilities for improvement.

    Also, about Windows cold start time measurement: perhaps it's impossible or very difficult to put the computer into the same state in which it is right after boot. But it's not only after boot that Fx takes long to start up, it's also after many other programs (that eat a lot of memory) have been used for a long time. Perhaps measuring startup speed from a state that just approximates this (and causes slow startup) is still much more valuable than not measuring anything at all, and thus having little to no idea about the effect of different optimizations.

    • Ferdinand says:

      If you want to know how fast Firefox could start in the future you should look at IE, Opera and Chrome. The Firefox developers are attempting to solve this problem in multiple ways: combine files to reduce disk seeking, compress files to reduce size, delay parts of Firefox starting, preload core parts and optimizing during idle time instead of during startup.

      • Zoog says:

        Well, if it will actually be made to start up as fast as any of those, then I will be very, very happy.

        Which version is expected to bring very noticeable results? 3.7? Or only later?

  2. […] can take a look at some of Firefox’s top startup bugs, which, once fixed, could improve startup time by 10% in some cases, and up to 25% in at least one […]

Leave a Reply

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

You are commenting using your 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