Firefox Startup Performance – January 15

Happy 2010 everyone!

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 Lots of progress! Joel has a patch for Mac and Linux working on the tryserver, and numbers to confirm a partial static build gets ~8% improvement on Mac, with no compat problems. Zach added a bunch of number crunching to validate Joel’s numbers. On the Windows front, Taras has a patch in progress now.
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 Ben is looking into a perf regression that arose after some major changes.
TBD 503483 Turn on –enable-faststart for Firefox by default Dietrich needs testing No update, need to test still. Maybe just push on Windows here.
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 irc.mozilla.org.


5 Comments on “Firefox Startup Performance – January 15”

  1. anonymous says:

    All this work regarding startup and I have not seen a single graph showing where exactly is each second spent. Haven’t you done any profiling of the startup as a whole, tools like gprof and kcachegrind and google perf tools come to mind…

    • Hi Anonymous!

      In this post I provided two different views of all JS executed in the startup path. Also, on the wiki page for the startup work (linked in the post) there are a bunch of different sources of information for where time is spent: dtrace logs, a timeline, filesystem usage and IO logs, canvas visualizations of this data. gprof has been used on Linux by Taras IIRC, but on Windows I’ve been using AMD CodeAnalyst. Also see some of the various blog posts by others that I link to, eg Rob Strongs detailed analysis of what JS XPCOM components are most costly during startup.

      But more data would definitely help! Maybe you could do a pass with gprof and kcachegrind and post your analysis back here?

  2. voracity says:

    Just curious, have you tried installing (say) the 30 or 50 most popular add-ons, and then using whatever profiling tools you use to inspect startup? What about filling up a profile with a “year’s” worth of history, changes, etc. and testing that? A comparison of these two to a fresh profile would be very interesting.

  3. voracity says:

    Heh, of course I could have just taken a look at your test coverage link…

  4. […] moc obliczeniowa domowych komputerów wzrosła kilkakrotnie!).  Dziś wszystkie przeglądarki walczą o ułamki sekund, choć zbliżamy się do granicy możliwości […]


Leave a comment