Firefox Startup Performance – Dec 14Posted: December 15, 2009
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:
- 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.