1536201 - site slow to load when debugger is open

Status: RESOLVED FIXED

(DevTools :: Debugger, defect, P1)

Description

[[e-mail] (:bhearsum)]

Thank you for helping make Firefox better. If you are reporting a defect, please complete the following:

What were you doing?`

I was debugging a locally run version of an app.

What happened?

Every time I refresh the page (to pull the latest code) it takes upwards of 30 seconds to load when the debugging toolbar is open. With it closed it's very fast. It's also fast in Chrome regardless of debugging toolbar status.

What should had happened?

It should be faster!

Anything else we should know?

I think this only happens after setting a breakpoint, and possibly it must be a breakpoint in a large file. However, the problem continues even if the breakpoint is removed.

Comment 1

[:Harald Kirschner :digitarald]

Thank you :bhearsum for the report – we are actively working to get the debugger more responsive and cut overhead!

If you can reproduce the issue in one of your projects, could you please record a performance profile following the steps here, share it and post the generated link here? Best would be recording in DevEdition or Nightly, as a lot of breakpoints code has changed in 67.

Instructions: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem

Comment 2

[[e-mail] (:bhearsum)]

(In reply to :Harald Kirschner :digitarald from comment #1)

Thank you :bhearsum for the report – we are actively working to get the
debugger more responsive and cut overhead!

If you can reproduce the issue in one of your projects, could you please
record a performance profile following the steps here, share it and post the
generated link here? Best would be recording in DevEdition or Nightly, as a
lot of breakpoints code has changed in 67.

Instructions:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/
Reporting_a_Performance_Problem

Will do in Nightly the next time I experience it.

Comment 3

[[e-mail] (:bhearsum)]

OK, Balrog permissions have been removed. I ended up temporarily granting myself tb-relman to avoid needing to bug someone from that group. https://bugzilla.mozilla.org/show_bug.cgi?id=1514684 for the ldap account removal.

Comment 4

[[e-mail] (:bhearsum)]

(In reply to [e-mail] (:bhearsum) from comment #3)

OK, Balrog permissions have been removed. I ended up temporarily granting
myself tb-relman to avoid needing to bug someone from that group.
https://bugzilla.mozilla.org/show_bug.cgi?id=1514684 for the ldap account
removal.

Whoops, wrong bug!

Comment 5

[[e-mail] (:bhearsum)]

Here's the profile: https://perfht.ml/2FpL7C3

Comment 6

[Logan Smyth [:loganfsmyth]]

Thanks for that, it helps a lot to nail down the bottleneck.

How large is the JS file that you are debugging in this case?

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Logan Smyth [:loganfsmyth] from comment #6)

Thanks for that, it helps a lot to nail down the bottleneck.

How large is the JS file that you are debugging in this case?

1.8MB.

If it's helpful, it's an app that's easy to run locally if you'd like to repro yourself.

Comment 8

[Logan Smyth [:loganfsmyth]]

If there's a codebase one of us can test that would be wonderful.

Comment 9

[[e-mail] (:bhearsum)]

(In reply to Logan Smyth [:loganfsmyth] from comment #8)

If there's a codebase one of us can test that would be wonderful.

If you clone https://github.com/mozilla/balrog and "docker-compose up", you should be able to load https://localhost:8010. I've been setting breakpoints in one of the "authorize" functions found in app.js to reproduce the issue.

Comment 10

[Logan Smyth [:loganfsmyth]]

Would you be able to post a screenshot or specific steps? I opened up https://127.0.0.1:8080/ which I'm assuming is the address you meant, and where there is an app.js I'm not sure if you mean the overall bundle or the sourcemapped original file. I also don't see functions on there called "authorize".

Comment 11

[[e-mail] (:bhearsum)]

(In reply to Logan Smyth [:loganfsmyth] from comment #10)

Would you be able to post a screenshot or specific steps? I opened up
https://127.0.0.1:8080/ which I'm assuming is the address you meant, and
where there is an app.js I'm not sure if you mean the overall bundle or
the sourcemapped original file. I also don't see functions on there called
"authorize".

Ah, sorry! I forgot that I was working on my own branch! You could probably reproduce with a breakpoint elsewhere, or you can use auth0 branch from https://github.com/mozbhearsum/balrog instead.

Comment 12

[Logan Smyth [:loganfsmyth]]

Looks like I end up with a 502 on your branch. I'll just post one fix I think will help at least and we can go from there.

Comment 13

[Logan Smyth [:loganfsmyth]]

Attachment: Bug 1536201 - Avoid calling findScripts() in a loop. r=jlast

Comment 14

[Logan Smyth [:loganfsmyth]]

I don't know why I'm having so much trouble recording profiles for this to compare my patches. Locally I'm seeing this patch take the getBreakpointPositions endpoint from 1.5-2s down to ~.1-.2 seconds, so it's definitely a big improvement, but I can't seem to get a good recording of it. Not sure why.

When this lands and goes out in the next nightly, it'd be great to get verification that it resolves the case you were seeing

Comment 15

[[e-mail] (:bhearsum)]

(In reply to Logan Smyth [:loganfsmyth] from comment #14)

I don't know why I'm having so much trouble recording profiles for this to
compare my patches. Locally I'm seeing this patch take the
getBreakpointPositions endpoint from 1.5-2s down to ~.1-.2 seconds, so
it's definitely a big improvement, but I can't seem to get a good recording
of it. Not sure why.

When this lands and goes out in the next nightly, it'd be great to get
verification that it resolves the case you were seeing

Sure! I'd also be happy to see if a try build (if it exists) fixes it.

Comment 16

[Logan Smyth [:loganfsmyth]]

Oh cool. I think https://treeherder.mozilla.org/#/jobs?repo=try&revision=a4f7d669922638c6d20d11c1678a3dfdbd55764e&selectedJob=235112719 is the last try run from this, so you can pull artifacts from there.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/b3889fbf6f8f
Avoid calling findScripts() in a loop. r=jlast

Comment 18

[[e-mail] (:bhearsum)]

(In reply to Logan Smyth [:loganfsmyth] from comment #16)

Oh cool. I think
https://treeherder.mozilla.org/#/
jobs?repo=try&revision=a4f7d669922638c6d20d11c1678a3dfdbd55764e&selectedJob=2
35112719 is the last try run from this, so you can pull artifacts from there.

This made a huge difference - it still takes a couple of seconds to load the huge app.js, but it's much faster than on Nightly, and no longer causes my fan to spin up. \o/

Comment 19

[Logan Smyth [:loganfsmyth]]

Great!

Comment 20

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/b3889fbf6f8f