Firefox Startup Performance – Dec 18

Not much change from my late post on Monday, but a few updates below. I’ll be out of the office as of this Monday, and back on 1/11/2010. If you’re starving for startup info during that time, hit up Taras, Joel and Planet Firefox for the goods. 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 Taras says mostly there.
>10% 525013 Investigate a more static build configuration of Firefox Joel Reymont Mac and Linux in progress Joel’s working on getting load of XPCOM components working now. Next step is completing runs of the performance tests on the tryserver.
up to 25% 514083 Per-file HFS+ compression on Mac OSX 10.6 Joel Reymont in progress Snow Leopard only. More testing needed to see if it’s feasible to compress at install-time, or if we’ll have to ship SL builds.
TBD 520309 Startup cache: replacement for fastload cache Ben Hsieh in progress Brendan suggested some significant changes, in-progress.
TBD 503483 Turn on –enable-faststart for Firefox by default Dietrich needs testing No update this week. 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 about 6% of startup spent parsing CSS.

Other activity this week:

  • More investigation into Hunspell changes in bug 468799, possibly incorporating some changes Chrome made.

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


6 Comments on “Firefox Startup Performance – Dec 18”

  1. Bug 524178 (read sessionstore.js in 1 chunk) also landed this week, which should help startup on slower devices.

  2. pd says:

    Still just 10% on Windows. *sigh*

    • Erunno says:

      If you had bothered to read the previous entries you’d know that startup time on Windows is already significantly shorter than on the other platform. Linux and Mac are playing catch-up so it’s naturally that their gains are larger than the already well-optimized Windows build.

  3. pd says:


    Exactly which comments are you referring to?

    It doesn’t matter than Linux/Mac are playing catchup, they are inferior platforms in terms of market share. Mozilla might not see it that way but they should.

    The core point is that if Firefox 3.6 only starts up 10% faster on Windows than Firefox 3.5, that is not good enough. It is still too slow. There needs to be at least a 50% improvement or just put a bloody splash screen up! Give the user feedback so they do not have to wonder what the hell is going on when the cursor turns from hourglass back to the default arrow and the bloody program STILL has not loaded.

  4. benedict says:

    Dietrich, I started a blog about my work as promised. Let me know if you have any feedback!

  5. Havvy says:

    @pd: Asking for arbitrary speed-up goals (such as 50%) is about the most useless thing to do in a post describing how speeding up Firefox is going. If there is only a 10% win for Windows right now, and you are not impressed, why don’t you search into Firefox’s internals and find out what is slow? If you cannot, then understand that all of those that can and want to are, but they are focusing on where the problem is most noticable: Mac & Linux. They don’t care if the win is only in “inferior” OSes, as seen in their actions.

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 )

Google+ photo

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


Connecting to %s