1602018 - Fission content process startup is slowing down pageload

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Randell Jesup [:jesup] (needinfo me)]

Comparing google docs performance in the tp6 testcase (live, not recorded) on a high-end linux box, I see a few hundred ms total lost before NavigationStart. e10s: https://perfht.ml/34WI2Vt fission: https://perfht.ml/2OVXKKL

At the very start, I see time in ConstructBrowser(), mostly in nsXPLookAndFeel::GetColorImpl() (~15ms), and time used loading a bunch of internal scripts: WebNavigationContent.js/FormAutoFillFrameScript.js/browser-content.js/tab-content.js/content-sessionStore.js; and running SessionStore::restoreHistory and restoreTabContent. This probably is in total less than 50ms; more like 30 perhaps. https://perfht.ml/2YmZfVy

Some of this may be mitigated by better prestarting/warming of content processes

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

looking at https://imgur.com/gallery/m5tYJL6, which shows 40-60% regressions on *speedindex:
non-fission: https://perfht.ml/2LSfaGz
fission: https://perfht.ml/2LEB1km

This is zoomed in on the start of navigation. Note that I'm starting at "keydown", which is is when I hit return on the URL. Also note that there's a 1 second delay from then until the content process starts (and then some delay in the new process). Note also that PageLoad starts in 20ms after keydown in non-fission, while it takes 1.1 seconds from keydown to "start" pageload...

Comment 2

[Chris Peterson [:cpeterson]]

Jesup, what we should do with this bug? Is this a meta bug?

Comment 3

[Chris Peterson [:cpeterson]]

Is this bug still a problem now that Jesup has landed content process preallocation? Some blocking bugs are still open, scheduled for Fission M7 and Future.