Firefox Startup Performance Weekly SummaryPosted: October 24, 2009
First, the numbers. This is the first round where all the posted numbers are from Talos. We’re getting closer to having Windows numbers for cold startup (details further down). The cold numbers didn’t have much in the way of results yet, only 3-5 boxes for today’s numbers, and given the variability we should probably put more boxes on those. The notable datapoint is that cold startup on Mac for 3.6 is better than for trunk, which is odd since it’s been the opposite in all of our manual testing, and most of the big wins haven’t made it to the branch yet. It could be because of the dearth of results so far. Next week I’ll include the dirty profile test results in these tables as well.
|Mac Leopard (10/23)||15605ms||13120ms (-16%)||13859ms (-11%)|
|Linux (10/23)||7056ms||7159ms (1%)||7204ms (2%)|
|Mac Leopard (10/23)||1451ms||1108ms (-23%)||1017ms (-30%)|
|Win XP (10/23)||459ms||462ms (0%)||449ms (-2%)|
|Win Vista (10/23)||535ms||544ms (1%)||506ms (-5%)|
|Linux (10/23)||625ms||632ms (1%)||629ms (0%)|
- Taras is zooming in on library IO, and posted some details and optimization approaches, and today posted a log of what’s loaded and how long it takes.
- Windows Cold Ts: As you can see above in the table, the new cold startup graphs are here for Mac and Linux. I’ve made progress on emulating cold startup on Windows using a utility from the Windows Server 2003 Resource Kit called Consume.exe. I found a reference to it in some random blog comment, and then found it on MDC as the #2 link on Google. The help file that the resource kit installer links from the start menu is… not actualy there, but I did find some tidbits of documentation. It will consume one of physical memory, cpu time, kernel pool memory, disk space (!) and the page file, for the number of seconds specified by the user. Running consume.exe for 15 seconds was enough to completely exhaust my physical ram, and subsequent starts of Firefox trunk are about 22 seconds. Next steps: I’ll continue to test to see what combination of these options gives us the best visibility into changes to cold startup time, and then work with Rel/Eng to get it deployed.
- Alfred Kayser landed bug 511754, which improves JAR file reading efficiency.
- Rob Strong has been making a bunch of changes in the update system to improve startup time, and posted a list of the changes.
- Drew has a patch up for bug 506814, getting rid of Change GetPersistentDescriptor/SetPersistentDescriptor on Mac, just needs review from Josh.
- Peter got review on bug 542615, removing the setTimeout 10ms wait in chrome JS.
- Ben Hsieh has been prototyping a whole Fastload cache replacement in bug 520309.
- Ben’s work on fastload cache invalidation in bug 511761 closed other bugs such as bug 517515 and bug 512827.
- Ted has been looking at re-enabling rebasing on Windows in bug 484799 for a potential performance boost there.
Projects in a holding pattern:
- Service caching work in bug 516085 still needs to be pushed to the Places branch for testing.
- Moving font-loading out of the startup path on Mac: Jonathan Kew filed bug 519445 with a WIP patch for yet further reductions in Mac startup time spent in font system initialization.
- 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. Need to list scenarios, 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.
- No updates on Zack’s CSS parser changes in bug 513149.