Warm start: ~900ms.  Cold start: ~10,000ms.  Youch.  The only difference between the two is disk IO; in the warm start case, most of the data has already been read in from disk, so looking at warm start can indicate where actual computation is taking place.  Using some instrumentation from bug 480735, here’s what the breakdown is like:

We do a bunch of work on the main thread asynchronously, including doing InitialReflow for browser.xul, which takes around 16% of the total time (bug 506416). Those numbers are actually with a patch for bug 506470; we were connecting to the Growl service early on in startup, for no good reason… and doing that connection was slow. Another mac-specific issue that’s patched out in the numbers above is doing initial checking of plugins, bug 506472.

Other things that are interesting is that doing UTF8 to UTF16 conversion shows up as single-digit percentages in the overall function profile. I’ve filed bug 506430 on optimizing UTF8 to UTF16, since this will affect pageload time as well, but bug 506431 is about figuring out how to avoid it entirely at startup, by fastloading more things (css and xbl, in particular).

I also spent a bit figuring out which timers are being fired at startup… there’s a bunch of stuff here, some of which we should be able to optimize. The dump there is on a startup stuff page.

I need to repeat all of this with cold startup, including figuring out why it’s taking so long to read the data that we have. We also need to figure out where each of the events that take significant amounts of time are coming from; the initial reflow for the main browser UI is a chunk of that, but there are still a bunch of events that are taking between 20-50ms.