1142623 - slow to open in-content preferences/about:addons as well as web page and open new window, if Browser Console has been opened

Status: RESOLVED FIXED

(DevTools :: Console, defect)

Description

[Alice0775 White]

Steps:
1. Open Browser Console Ctrl+Shift+J
2. Open in-content preferences Tools > Options

Actual Results:
It takes avout 1-2 sec

Expected Results:
Should be instant

Comment 1

[Alice0775 White]

Pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=28a727d25fa7&tochange=7697ad4919e7


Regressed by: Bug 1059308

Comment 2

[Alice0775 White]

also slow to open about:addons

Comment 3

[Alice0775 White]

[Tracking Requested - why for this release]:

Comment 4

[Alice0775 White]

Also affected to normal web page.
Steps:
1. Open Browser Console Ctrl+Shift+J
2. Open https://support.mozilla.org/en-US/kb/get-started-firefox-overview-main-features
3. Try to scroll the page while page is loading

Actual Results:
Browser becomes unresponsive for 10 seconds or so.

Expected Results:
Browser should respond



Another steps
1. Open Browser Console Ctrl+Shift+J
2. Open new window Ctrl+N

Actual Results:
Browser becomes unresponsive for 10 seconds or so.

Expected Results:
Browser should respond


All of the abobe, same regression range of comment#1

Comment 5

[Alice0775 White]

s/abobe/above/

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking since this is a major performance regression.

The slow response for about:preferences looks to be true with or without e10s.

Comment 7

[Alexandre Poirot [:ochameau]]

The profiler seems to designate this method as performance culprit:
http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/utils/map-uri-to-addon-id.js#40
  mapURIToAddonID

I need to verify this...
We may be calling this method more often as we track more documents.

Comment 8

[Alexandre Poirot [:ochameau]]

Attachment: Prevent enabling Debugger in Browser Toolbox during its startup

Ok, so I think the main regression of bug 1059308 is that, due to new TabActor code,
we always enable ThreadActor's debugger and its various listeners.

I think we can also ensure that enabling the thread actor won't cost so much when enabled...

This `if (this.threadActor.dbg)` check seems useless as dbg getter always returns a Debugger instance.

Comment 9

[Alexandre Poirot [:ochameau]]

At the end it doesn't look like mapURIToAddonID is the debugger performance culprit.
So far I've only been able to track it down to onNewScript/addScript:
  http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js#2026

We are calling _addScript *a lot* when opening about:addons/about:preferences (actually, doing anything in Fx UI is going to dispatch a lot of calls).
It looks like the first time we call _addScript for a new source, it takes a significant time, between 3 and 10ms. Then the next time we call _addScript for the same source it is most of the time under 1ms.

James, any random guess?

Comment 10

[Panos Astithas (he/him) [:past] (please ni?)]

Comment on attachment 8578661 [details] [diff] [review]
Prevent enabling Debugger in Browser Toolbox during its startup

Review of attachment 8578661 [details] [diff] [review]:
-----------------------------------------------------------------

I added the threadActor.dbg check in bug 740551 that implemented chrome debugging (I think because a test was failing), but this code has changed a lot in the last 2.5 years, so it may well be unnecessary now.

Comment 11

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=4ebe84e9ab94

Comment 12

[James Long (:jlongster)]

(In reply to Alexandre Poirot [:ochameau] from comment #9)
> At the end it doesn't look like mapURIToAddonID is the debugger performance
> culprit.
> So far I've only been able to track it down to onNewScript/addScript:
>  
> http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/
> script.js#2026
> 
> We are calling _addScript *a lot* when opening
> about:addons/about:preferences (actually, doing anything in Fx UI is going
> to dispatch a lot of calls).
> It looks like the first time we call _addScript for a new source, it takes a
> significant time, between 3 and 10ms. Then the next time we call _addScript
> for the same source it is most of the time under 1ms.
> 
> James, any random guess?

The `_addScript` function is called once for every JavaScript source. If there are a lot of JS sources, it can add up and be slow. Some of this is just the nature of connecting devtools -- it's going to make stuff slower. However, we plan on trying to optimize it, but 3-10ms per source honestly does not sound that bad.

I don't have enough context, but yes, connecting the debugger is going to make the initial page load slower.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/fx-team/rev/9428297d9218

Comment 14

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/9428297d9218

Comment 15

[Gabriel]

seems not fixed at all. when I open about:addons or Console (Ctrl+Shift+J) or Speed Dial [FVD] - New Tab Page, Sync... 7.0.1 (new tab) take 6~10 sec to full load the content, sometimes takes much more.
I'm on firefox 39.0beta1