I've been digging into startup time for the past little while, looking at both warm and cold startup, and trying to figure out where some of the pain lies. So far I've only been looking at MacOS X, mainly because it has an easy way to flush filesystem caches ("purge"); I'd be doing this work on Windows if there was something similar there.
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:
| 0.6% | XRE startup |
| 0.1% | pre-XPCOM startup |
| 12.4% | XPCOM, network, app-startup |
| 9.6% | CreateHiddenWindow |
| 8.9% | EM & cmdline |
| 65.7% | Main thread event processing |
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.
There was talk of using UTF8 internally, https://wiki.mozilla.org/Mozilla_2/Work_List mentions
‘”Strings” — sharing strings with JS or moving to STL, moving to UTF8, sanifying the existing string classes – bsmedberg ‘
and Mr. O’Callahan in http://weblogs.mozillazine.org/roc/archives/2008/01/string_theory.html wrote
“I think it would be very interesting to try just having a single string type that was UTF-8 … [lots of details]”
It never became a bug, just an area for analysis.
As Gecko goes to smaller increments (1.9.1 -> 1.9.2), does Mozilla2 get further away ? :-)
On Linux:
To free pagecache:
echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
echo 3 > /proc/sys/vm/drop_caches
I took your implied challenge, and I made a 48KB no-dependency binary to empty Windows’ file cache. It uses a lovely undocumented API, so I blogged about it with binary and source links for posterity: http://twpol.dyndns.org/weblog/2009/07/29/01. :)
Sweet! It turns out there is a sysinternals tool called CacheSet that seems to do exactly the same thing. My google skills failed; shaver found this the other day. However, I like yours better since it’ll work on the command line. Thanks!