Closed
Bug 1373148
Opened 8 years ago
Closed 8 years ago
_createPreloadBrowser takes 25ms and loads content scripts in the parent process
Categories
(Firefox :: Tabbed Browser, enhancement)
Firefox
Tabbed Browser
Tracking
()
RESOLVED
DUPLICATE
of bug 1353013
Performance Impact | ? |
People
(Reporter: mstange, Unassigned)
Details
Profile: https://perfht.ml/2ryoZfv
I noticed a janky tab close animation and looked at the profile. It looks like we were create a preload browser just before the last frame of the tab close animation had a chance to paint. In the process, we were evaluating a few scripts, most of which I would only expect to see in the content process.
Comment 1•8 years ago
|
||
Perhaps we should consider invoking `this.tabbrowser._createPreloadBrowser` (http://searchfox.org/mozilla-central/rev/c49a70b53f67dd5550eec8a08793805f2aca8d42/browser/base/content/tabbrowser.xml#6612) in an idle dispatch, as I don't think we don't need to do it immediately (we're _pre_loading a tab which isn't being switched to yet), and creating a xul:browser ain't exactly cheap.
Marking [qf], 'cause it seems related.
Tim, does that seem like a reasonable approach to take?
Flags: needinfo?(ttaubert)
Whiteboard: [qf]
Updated•8 years ago
|
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Comment 3•8 years ago
|
||
(In reply to Michael Layzell [:mystor] from comment #1)
> Perhaps we should consider invoking `this.tabbrowser._createPreloadBrowser`
> (http://searchfox.org/mozilla-central/rev/
> c49a70b53f67dd5550eec8a08793805f2aca8d42/browser/base/content/tabbrowser.
> xml#6612) in an idle dispatch, as I don't think we don't need to do it
> immediately (we're _pre_loading a tab which isn't being switched to yet),
> and creating a xul:browser ain't exactly cheap.
>
> Marking [qf], 'cause it seems related.
>
> Tim, does that seem like a reasonable approach to take?
Yeah, seems worth a try to me. Preloading after all is just an optimization, if we didn't preload the browser won't break.
Flags: needinfo?(ttaubert)
Reporter | ||
Comment 4•8 years ago
|
||
(In reply to Markus Stange [:mstange] from comment #0)
> In the process, we were evaluating a
> few scripts, most of which I would only expect to see in the content process.
I think this is just because the new tab page still runs in the parent process. The cost of this should go down once Activity Stream gets enabled.
Comment 5•8 years ago
|
||
Can you reliably reproduce this bug? It might be nice to get another profile of this with activity stream enabled as well. The pref is called "browser.newtabpage.activity-stream.enabled".
Flags: needinfo?(mstange)
Reporter | ||
Comment 6•8 years ago
|
||
I can easily reproduce this just by pressing Cmd+T a few times. If I look at the profile, I see about 15ms inside each call to _createPreloadBrowser, most of which is spent loading the scripts.
If I enable Activity Stream with that pref, the time in _createPreloadBrowser goes down to as little as 3ms, but spends all of its time waiting on a sync IPC message: PCompositorBridge::Msg_NotifyChildCreated.
If the compositor is currently compositing or uploading textures, it can block for longer, e.g. I have one instance in my profile where it takes 23ms.
If PCompositorBridge::Msg_NotifyChildCreated were async, _createPreloadBrowser probably wouldn't show up at all in the profile.
Flags: needinfo?(mstange)
Reporter | ||
Comment 7•8 years ago
|
||
I filed bug 1373773 about that.
Updated•3 years ago
|
Performance Impact: --- → ?
Whiteboard: [qf]
You need to log in
before you can comment on or make changes to this bug.
Description
•