1950491 - Improve BrowserChild construction with fission (28ms)

Status: NEW

(Core :: DOM: Content Processes, enhancement)

Description

[Thinker Li [:sinker]]

According to bug 1786466, content processes receive PContent::Msg_ConstructBrower to construct a BrowserChild before loading the content. It take additional ~28ms to handle related messages. This only happens to fission and changes the timing of refresh driver, postponing rendering and composition. It causes the regression of XXXSpeedIndex mentioned earlier. CanonicalBrowsingContext::ChangeRemoteness() will call ContentParent::CreateBrowser() to create a BrowserChild. If it performs earlier, the content process would get ready earlier. (Do it before receiving nsHTTPChannel response? Not wait for it..) Or, we can reduce the tasks caused by the construction of BrowserChild.

• https://bugzilla.mozilla.org/show_bug.cgi?id=1786466#c7
• https://share.firefox.dev/42VXjGI

Comment 1

[Jens Stutte [:jstutte]]

It appears to me that in that profile inside ContentChild::RecvConstructBrowser we see mostly the overhead of nsDocShell::CreateAboutBlankDocumentViewer.

And IIUC the pagehide event that causes the creation to happen is fired via willChangeBrowserRemoteness from the parent, there might be potential for firing this earlier ? At least there seems to be a 10ms pause on the main thread right before, not sure why. And there is also quite some JS code executing before on the main thread between Navigation::Start and WillChangeBrowserRemoteness.

Comment 2

[Thinker Li [:sinker]]

With the suggestion from Markus, This is the profile with '--enable-release'. It takes about a similar additional time to handle ContentChild::RecvConstructBrowser . (~24ms)

https://share.firefox.dev/4kmSJI3