Closed
Bug 1356561
Opened 7 years ago
Closed 7 years ago
Delay remote process initialization until after window is shown
Categories
(Firefox :: Tabbed Browser, enhancement)
Firefox
Tabbed Browser
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: enndeakin, Unassigned)
References
(Blocks 1 open bug)
Details
On my fast system, the native window is created at about the 615ms mark. The window is shown at about 1120ms. The content process for the default tab is started and various scripts loaded after the main window is created but before it is shown. I tested disabling the call to updateBrowserRemoteness within the browser.js DOMContentLoaded handler (to avoid starting any remote process handling at startup) and this causes the main window to show about 50-80ms earlier (4-7% of the total startup time). For a second new window the time between creating and showing a window is reduced by up to 15% (230ms to 200ms) This occurs whether I have a home page set or whether it is set to show a blank page. To speed up window show time, we should consider delaying the remote process handling until after the window is shown.
Updated•7 years ago
|
Flags: qe-verify?
Priority: -- → P2
Whiteboard: [photon-performance]
Comment 1•7 years ago
|
||
Neil, do you have a profile? I think it's definitely understandable to not want to run the updateBrowserRemoteness bits at the time you suggested, but I think delaying the starting of the content process even further is even worse. We should try to start the first content process even earlier if possible. I think perhaps one architectural problem right now is that the starting of the content process is tied to the browser window. Gabor, Blake, have you guys ever thought about disentangling these two things? Perhaps this would automatically be taken care of with a preallocated content process?
Flags: needinfo?(mrbkap)
Flags: needinfo?(gkrizsanits)
Comment 2•7 years ago
|
||
(In reply to Neil Deakin from comment #0) > This occurs whether I have a home page set or whether it is set to show a > blank page. Is this a browser startup or just opening a new window? I think there is a bug that we create and throw away a content process for no good reason... (Bug 1352021). For a blank page we should not need a content process to start with. > > To speed up window show time, we should consider delaying the remote process > handling until after the window is shown. Delaying might be the wrong approach, but somehow decoupling the two should be considered for sure. (In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #1) > Gabor, Blake, have you guys ever thought about disentangling these two > things? Perhaps this would automatically be taken care of with a > preallocated content process? The preallocated content process will hide some of these issues to some extent but we should still find a solution here if possible.
Flags: needinfo?(gkrizsanits)
Reporter | ||
Comment 3•7 years ago
|
||
> Is this a browser startup or just opening a new window?
Both.
Updated•7 years ago
|
Priority: P2 → P3
Whiteboard: [photon-performance] → [reserve-photon-performance]
Comment 4•7 years ago
|
||
Discussed in Photon Performance team meeting - decision to mark as 'WONTFIX'.
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: qe-verify?
Priority: P3 → --
Resolution: --- → WONTFIX
Whiteboard: [reserve-photon-performance]
Comment 5•7 years ago
|
||
(In reply to Marco Mucci [:MarcoM] from comment #4) > Discussed in Photon Performance team meeting - decision to mark as 'WONTFIX'. The reason for wontfixing is that there's another competing bug asking to create the content process(es) as soon as possible during startup.
Updated•7 years ago
|
Flags: needinfo?(mrbkap)
You need to log in
before you can comment on or make changes to this bug.
Description
•