Devtools slow and occasionally unresponsive on some sites

Developer Tools
#23

That said, we can already see that the main thread hang is caused by the debugger. I know the debugger folks did a lot of performance improvements lately and they’re probably not in v58, some are in Nightly but maybe not all of them yet. Do you think you could try your workload on a recent nightly version too ?

Last thing: by chance, do you have a public-facing website where the issue happens that we could try ? Or a github repo that we could build and run to reproduce the issue ?

Thanks again for your help !

–
Julien

#24

I took a couple more profiles. They are both from the most recent nightly build (59.0a1).

Overall it seems the performance on Nightly is a bit better, though still not great. FWIW, the page load is consistently under 3s when devtools are not open.

Unfortunately I can’t share a direct link to the page, and it’s not open source. I can spend some time this afternoon creating a sample project and see if I can get it replicating that way. I’ll update you with a link if I can reproduce in a small project.

Thanks for looking into this!

#25

I have a similar issue. It’s a lot better with 59.0a1 than with 58.0b8 but the debugger still slow. When a big JS file loaded, like the one I have for my Ember.js project, it took at least 2go or ram and it increase when I reload the page. Here is some information : https://perfht.ml/2BHHJiZ .

#26

Same problem here. And I have a specific example for you.

Go to https://www.xome.com/Listing/ListingSearch.aspx and Inspect any element on the page. It takes several seconds to get to the correct node.

For issues with stepping through code, search sources for displayPins function - you should be able to find it in BingMapv8Wrapper.js (it lists it twice for whatever reason). Place a breakpoint on the first line of the function. Go back to the page, switch to Map view (by clicking on the Map link in top left part of the page). Move the map around to cause it to breakpoint. It takes 2-3 seconds or so for every line - very painful.

I get that the page contains a metric ton of js - but lots of things these days do.

#27

Same here :frowning: I found the developer edition too slow to be usable so have reverted to firefox 55 with firebug.

1 Like
#28

Thanks for the info! The slowness to pick an element seems linked to the issue discussed in https://bugzilla.mozilla.org/show_bug.cgi?id=1412319

#29

Is it possible to have updates from the Firefox team. Is there a place to follow the works on this bug?

#30

I’ve not found any issue in Mozilla bug tracker. Is this bug already declared?

For me it’s impossible to use Firefox to debug my app as it takes more than 14 seconds to load the page…

#31

The debugger team is working on several performance-related items. Right now we are trying to land improvements for projects using source maps.

All the work is made on GitHub at https://github.com/devtools-html/debugger.html. If you can file an issue there with clear steps to reproduce, it will help the team address your issue.

#32

We have several bugs in Bugzilla and GitHub to track specific performance issues. Can you give more details about your issue (URL if it is public, which panel is selected in DevTools etc…).

Then I can either point you to an existing issue or open a new one. Thanks

#33

The URL is not public as it’s a local development.
I’m building an app using Bootstrap and Dojo. When the page loads, it performs 281 requests (mainly js + css files).

The same page takes 2.5 seconds to load with Chromium.

It doesn’t depend on which panel is open. I’ve tried with Console, Memory, Network and Performance and I always have the same time to load the page. If the devtools are closed, the page load in 2-3 seconds.

#34

Thanks for the info. Would you be able to capture a performance profile using the profiler at https://perf-html.io/ ?

Maybe it is a panel which was loaded and then hidden. To make sure if a panel impacts or not the reload time you can do the following steps:

  • select the panel (e.g. console)
  • close devtools (F12)
  • open devtools (F12) (it should still be on the console, don’t change the selected panel)
  • reload your page

Any extra info can help!

#35

Sorry, in fact the panel impacts. If I open devtools in console directly, the page lors in 3.9s each time. If I open the network panel it can spend more than 12 seconds.
I’ll try to give you a performance profile.

#36

Thanks for checking. There has been a decent amount of performance work in the Network panel recently. If you are not already using Nightly, it would be worth checking the performance there.

#37

I’ve tried using nightly and there is a little improvement (9 sec instead of 12 sec) but the problem is still present.
Here is the perf without opening the network panel : https://perfht.ml/2CYFNmU
The perf with the network panel open : https://perfht.ml/2oFPlAh
I don’t know how to analyze it so let me know if you there is something I did wrong.

#38

Thanks for the profiles @tony . They highlight a couple methods to investigate already. I found https://bugzilla.mozilla.org/show_bug.cgi?id=1350969 which tracks performance improvements for the Netmonitor and added links to your profiles there.

#39

I tried to find a stable way to reproduce the bug but I don’t have the same behavior. I always have a lot of memory usage but not always in the same range. Sometimes is 2go and sometimes it’s 6go for the same page with the same navigation.

Here is the result of one single page loading when I go to the debugger :

firefox-1
firefox-1.png721×381 38.6 KB

firefox-2
firefox-1.png873×599 81.8 KB

As you can see the CPU is going crazy. The page took about 5 seconds to load but the memory usage increase and the CPU is used for about 30 seconds. If I reload more times, it still continue to use memory.

I went on all tabs of the dev tool and it works well but it goes crazy when I go on the debugger.

It works nicely with Firefox 57. It do this only with the local version of my app but it’s correct with the compressed version in production.

I will try to find a way to reproduce the bug with an online app.

#40

Any news on this front. I have the same issues as mentioned above (debugger tab takes many seconds to open, moving line to line (F10) takes 2-3 seconds each time) mousing over a variable takes a long time to show its value)? Using FF 57.0.3

I have another issue where a bunch of breakpoints keep coming back no matter how many times I remove them.

#41

| Any news on this front […] Using FF 57.0.3

Stepping (F10) performance has been improved on 59 already. “Opening the debugger” can be slow for various reasons, we are still working on improvements related to sourcemaps. If you have a link with steps to reproduce your issue, the best is to open a ticket on https://github.com/devtools-html/debugger.html/issues

Always worth trying Nightly, as we have been landing several performance improvements to the debugger in Firefox 59.

| I have another issue where a bunch of breakpoints keep coming back
| no matter how many times I remove them.

I thought most “breakpoints” issues were fixed before 57 :confused: . As a workaround you should be able to go to about:config and look for “devtools.debugger.pending-breakpoints”. Could you copy the value and report it here? After that you can right click and “Reset” the value. Hopefully it should remove those persistent breakpoints.

#43

Hi, I’ll check out the Nightly .
I’d rather not have the contents of “devtools.debugger.pending-breakpoints” on a website. Can I send it to you privately?