Closed Bug 533944 Opened 15 years ago Closed 9 months ago

Comparative analysis of Chrome (Beta), Safari and Firefox startup

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86_64
macOS
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: joelr, Unassigned)

References

(
URL
)

Details

(Whiteboard: Ts)

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
The previous VM fault stats were weighted by CPU time. It's even more interesting to weight VM faults by wait time Safari Chrome Firefox File-backed page in 245.8ms 2.1s 2.1ms Page cache hit 0 41.6ms 2.8ms Zero fill 0 5.1us 5.1us Copy on write 0 11.1ms 42.5ms and total time File-backed page in 256.7ms 2.1s 2.1s Page cache hit 9ms 54.4ms 12.6ms Zero fill 6.3ms 12.6ms 26.4ms Copy on write 2.2ms 19.9ms 48.4ms Note that - "File-backed page in" is fetching pages from disk. - "Page cache hit" is fetching previously unmapped pages from the cache. - "Zero fill" is memory allocation. Any allocations > 15K are done via the virtual memory manager and have to be zero-filled for security reasons, lest people decide to snoop deallocated pages for sensitive data [1]. - "Copy on write" is duplicating pages that need to be modified. [1] http://lists.apple.com/archives/PerfOptimization-dev/2008/Nov/msg00033.html Here's what I understand from the above: 1) Safari is really small and light. Indeed, the binary is just a tad over 5Mb. Safari uses just 2 shared libraries: sqlite and icu, the open source unicode library. The bulk of Safari is system frameworks, e.g. WebKit, JavaScriptCore, AddressBook, etc. 2) Safari startup is tightly managed with optimized code. There's minimal allocation of memory that involves the virtual memory manager and there's minimal data modification. 3) Chrome is as huge as Firefox. All of its functionality is packaged into the 37Mb Chrome framework. The framework does not use any dynamic libraries worth mentioning (crypto, stdc++, objc, gcc and System), everyone uses those. 3) I'm not sure what to make of Chrome's 54.4ms use of the page cache. There's nothing wrong with it since the page cache is in memory. My hunch is that this means more code locality that Firefox given that Chrome has about as much code as we do. 4) We are as huge as Chrome. XUL is 40Mb vs 37Mb in the Chrome framework. We have 10Mb of extra shared libraries, though. 5) We are doing too many allocations that are too big and thus require zero-filled pages from the memory manager. 6) We modify -way- too much stuff on startup, thus the comparatively large amount of time copying pages on write.
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.

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: joelr → nobody
Severity: normal → S3

All the browser engines have changed massively changed in these years. Closing this bug.

Status: NEW → RESOLVED
Closed: 9 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.