821032 - Script debugger (TA_addDebuggee) appears to cause multi second pause while surfing

Status: RESOLVED DUPLICATE of bug 832163

(DevTools :: Debugger, defect, P3)

Description

[Benoit Girard (:BenWa)]

I turned on the remote debugger server on this instance of Firefox and connected using the remote console and later I noticed some hang on page with non trivial JS. These pages are normally fast while now the browser will have 5+ second pauses:

people.mozilla.com/~bgirard/cleopatra/#report=47ea9bf68ff379698dfb0e8560806e13e79580a1&search=TA_addDebuggee

STR:
1) Turn on desktop firefox instance set devtools.debugger.remote-enabled;true
2) Open the debugger to start the remote debug server.
3) Connect from another instance.
4) While surfing I notice multisecond pauses

Most of the slow stacks appeared to be correlated to dbg-script-actor

Comment 1

[Benoit Girard (:BenWa)]

Clickable url:
http://people.mozilla.com/~bgirard/cleopatra/#report=47ea9bf68ff379698dfb0e8560806e13e79580a1&search=TA_addDebuggee

Comment 2

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

Does it still happen if you apply this patch:

https://bug818134.bugzilla.mozilla.org/attachment.cgi?id=692340

Comment 3

[Benoit Girard (:BenWa)]

I don't have time to test this but I'll give it another shot once a patch hits nightly.

Comment 4

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

Actually, scratch comment 2. That patch shouldn't have made any difference.

Comment 5

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

From the profile it looks like you were debugging chrome, is that correct? In comment 0 you mention opening the remote console, which makes me suspect that perhaps you didn't mean to do that. If you were using Nighty with the new "Connect..." menu item, then selecting the 'Remote Process' target from the target list will get you exactly that: a global console (equivalent to the old Error Console) and a chrome debugger, that adds all globals as debuggees, significantly affecting performance as a result.

If that is what happened, then rest assured that we are working on making the Remote Process target's purpose more obvious, and less likely to be picked by accident.

Comment 6

[Benoit Girard (:BenWa)]

I ran step 2 because without step two the server isn't listening on the port. Perhaps there is a better way to get the server started.

Comment 7

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

Actually it's not a server issue. Starting the server will create actors for both content and chrome debugging. It's the client which decides what actor to connect to, and the connection target list has the Remote Process link that corresponds to chrome debugging.

Comment 8

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

Benoit, bug 832163 will provide a way to start a debugger server on desktop. Will that satisfy your needs for this bug? If so, should we close/dupe it?

Comment 9

[Benoit Girard (:BenWa)]

(In reply to Panos Astithas [:past] from comment #8)
> Benoit, bug 832163 will provide a way to start a debugger server on desktop.
> Will that satisfy your needs for this bug? If so, should we close/dupe it?

I don't really think it will. It felt like the performance overhead was simply too high. But feel free to close/dupe it and I file a bug once I try out the new way if the problem is still there, profiling is easy.

Comment 10

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

Closing per comment 9.