After I looked at Telemetry data from users with super-slow startups, I decided to take another look at my own about:telemetry page for comparison.
First off, there were 9 SQL statements on the main thread which required longer than 100ms to execute, as well as 46 slow SQL statements on other threads. This is a bit worse than usual for my about:telemetry page + a bit surprising since my machine is a recent i7 laptop with a 7200rpm drive, running on a “maximum performance” power profile. My first suspicion fell on a busy session restore period with 5 windows and ~50 tabs but my browser was not configured to actually load the pages in the background tabs on session restore. I took some comfort in knowing that most of the components which executed those main-thread queries are already being refactored to do async I/O instead.
I was also pretty surprised by the distributions found in a few of the histograms in about:telemetry. My CACHE_DISK_SEARCH histogram, which represents the number of milliseconds to search the disk cache (grouped into buckets), had a surprisingly long tail, with 11 cache reads requiring 100ms or more:
(click for full size)
(click for full size)
20ms main 1856ms createTopLevelWindow 2806ms firstLoadURI 4025ms delayedStartupStarted 4011ms firstPaint 4060ms sessionRestoreInitialized 4062ms sessionRestoreRestoring 4604ms delayedStartupFinished 6461ms sessionRestored