thanks for the profile ! We can see there are clearly big 16-second hangs: one in the content (the page itself), one in the main thread (likely the devtools, but could be something else). Is it what you experience too ?
However the profile is not very actionable because it’s cut up; the reason is that the default settings for the profiler are too low for a long profile. Could you please record it again after changing the “buffer size” setting to something like 180MB ? You can access this setting by clicking on the gecko profiler icon, then expand the “setting” lower panel.
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 ?
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.
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 .
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.
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.
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
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.
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.
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.
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.
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.
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 :
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.
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.
I found the developer edition too slow to be usable so have reverted to firefox 55 with firebug.
