It has been next to impossible to figure out where Firefox startup time is going on the Mac. Shark and Instruments show us spending very little time on the CPU but Vlad's timer shows us spending 3-4s starting up. I thought I'd take a different tack and see how Firefox (64-bit) startup compares to Chrome Beta (32-bit) and Safari (64-bit). To summarize, we are dead last, Chrome Beta is in second place and Safari takes the startup prize by starting almost instantly. What are they doing that we don't? I think the results of a Shark System Trace profile hint at the direction we should be moving. I wasn't able to rig a precise test where each browser quits as soon as an empty page is displayed so I resorted to stopping profiling (Opt-Esc) as soon as I saw the empty page. Also, I'm running each browser from an external USB HD and using this script to purge the Unified Buffer Cache (UBF) by unmounting and re-mounting the file system. #!/bin/sh diskutil unmount force /Volumes/Fujitsu80Gb diskutil mount /dev/disk1s2 Safari Chrome Firefox Total CPU Time 343.8ms 529.6ms 805.8ms User 273.2ms 424.8ms 653.1ms System 70.6ms 104.8ms 152.7ms Syscalls 40.3ms 50.6ms 78.7ms VM Faults 28.5ms 50.9ms 70.3ms Focusing on VM faults... File-backed page in 11ms 16.9ms 28.2ms Page cache hit 9ms 12.7ms 9.8ms Zero fill 6.3ms 12.6ms 26.4ms Copy on write 2.2ms 8.8ms 5.9ms Focusing on the main thread... Syscall waits 59.9% 43.6% 39.8% 875.2ms 1.7s 1.8s VM fault waits 16.8% 43.6% 42.8% 245.8 1.7s 2.0s
My hardware is a unibody 15" MBP, 2.93Ghz, 4Gb of memory, 256Gb Apple SSD. I'm running off of an external USB HD that I eject and mount again to clear the Unified Buffer Cache (UBC), i.e. get rid of the mmap-ed code in memory. Safari startup is almost instantaneous for me, 1-1.5s. Chrome is somewhere around 2s. Firefox is 3.5-3.7s. I profile Firefox on the second run since the first does component registration, takes at 1-1.5s longer and we don't care about it. Note the ZIP with the 3 Shark profiles in the URL field of this bug! Feel free to take a look and comment.
I'm almost positive that Safari is using HFS compression (bug 514083) whereas Chrome and Firefox do not. HFS compression is a huge win on Snow Leopard and I see no reason why we shouldn't take advantage of it.
That comparison is very interesting, thanks for posting that. You are probably running a chunk safari off ssd since it's so tied into the OS. I doubt it's only 5mb worth. Any writes(to files) during startup are bugs. We should not be writing during startup. Collect backtraces from what the heck is writing to files and file bugs. As I mentioned on irc: try compressing all of our system files. I think only the updater needs to write to those and it replaces files instead of modifying them, which should work fine.
Taras, basically all of Safari frameworks are in the dyld library cache (bug 513076). More likely than not, these would be in memory by the time I run Safari.