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

NEW
Assigned to

Status

()

Firefox
General
8 years ago
4 months ago

People

(Reporter: joelr, Assigned: joelr)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Ts, URL)

(Assignee)

Description

8 years ago
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
(Assignee)

Comment 1

8 years ago
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.
(Assignee)

Comment 2

8 years ago
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.
(Assignee)

Comment 3

8 years ago
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.

Comment 4

8 years ago
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.
(Assignee)

Comment 5

8 years ago
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.
You need to log in before you can comment on or make changes to this bug.