Firefox Startup Performance – January 22

A good week: Firefox 3.6 was released, and I’ve gotten a lot of feedback from friends and colleagues that startup has improved, and that it’s snappier than ever. Yesterday I blogged a roundup of the performance improvements in Firefox 3.6.

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 is traveling, says he’ll close it out when he returns.
>10% 525013 Investigate a more static build configuration of Firefox Joel Reymont in progress More great data from Zack and Joel. See PDF charts of the different build configurations tested on different hard-drive speeds for Mac and for Linux.
up to 25% 514083 Per-file HFS+ compression on Mac OSX 10.6 Joel Reymont in progress Conclusion is that we need to make this happen via the installer, as well as the updater, since modifying files results in decompression. Need to find an owner for this still.
TBD 520309 Startup cache: replacement for fastload cache Ben Hsieh in progress Considering moving back to the simpler caching approach.
TBD 503483 Turn on –enable-faststart for Firefox by default Dietrich needs testing Started talking with Rob Strong about making the changes to the NSIS installer to make this happen.
TBD 513149 Speed up CSS parsing by using a machine generated lexer Zack Weinberg Zack’s blocked on other work No update.Taras says about 6% of startup spent parsing CSS.

Other activity this week:

Projects in a holding pattern:

  • More investigation into Hunspell changes in bug 468799, possibly incorporating some changes Chrome made.
  • 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 – January 22”

  1. Rasmussen says:

    Well, i don’t see any improvement in my startup time, even after 3.6. I have about 30 add-ons that could be the reason?

  2. Very good text. I’ve found your site via Bing and I’m really glad about the information you provide in your articles. Btw your sites layout is really messed up on the Kmelon browser. Would be great if you could fix that. Anyhow keep up the good work!

  3. Jean Couprie says:

    Please clarify “Dirty Profile Testing”.
    Does that means profiles that :
    -contains errors ?
    -contains useless lines ? E.g. commented lines, accounts that are no more in use, etc. .
    -need a Windows (or other OS) “defrag” ? As the users do not defrag often the partition that contains the profile, the time to read the files from disk may be significantly longer than if the test profile has been “defragmented” : in this case the time measured during the test is meaningless for the users… Fragmentation slows at start up the loading, during normal processing the execution. The files should be defragmented periodically e.g. at installation or update time of Firefox (or other Mozilla programs) that means nearly each month.
    Think to the huge (>42MO. for me) urlclassifier3.sqlite or any other big files. Think to have this file only once in the system and not in each profile because it is the database for dangerous sites and should be the same in all profiles. It is very easy to have the file in each profile because when the user run a profile he has the right in it and update the files. It is far more difficult to have a central file that each user profile has the right to update but the anti-virus knows how to have only one signature database system wide which is updated by the user presently connected. Anti-virus is always installed by the administrator but Firefox is also installed by the administrator in 99 % of the cases. I have a dozen of profiles in my PC that means >500 MO. to download and update… And profiles that are not used often are not well protected… I am not sure if we have only to defrag this file or also to execute ‘sqlite urlclassifier3.sqlite “VACUUM” ? How does this sqlite program compares to WOT extension ?

Leave a Reply to Justin Campusano Cancel 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