Closed Bug 1373148 Opened 7 years ago Closed 7 years ago

_createPreloadBrowser takes 25ms and loads content scripts in the parent process

Categories

(Firefox :: Tabbed Browser, enhancement)

enhancement
Not set
normal

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.
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]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
(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)
(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.
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)
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)
I filed bug 1373773 about that.
Performance Impact: --- → ?
Whiteboard: [qf]
You need to log in before you can comment on or make changes to this bug.