User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36 Steps to reproduce: 1. Load the following page http://todomvc.com/examples/backbone_require/, it loads pretty quickly 2. Open Developer Tools 3. Reload the page again, see how much slower it loads This problem is much worse when working with a larger app with a lot more files being loaded, I'm seeing a much more complex app (lots of files) load time go from 1s to 17s when developer tools is open Actual results: https://perf-html.io/public/82cf42dbe3ddae498a88a7d258622eb67de8cfd5/calltree/?hiddenThreads=&range=2.0178_3.6985&thread=0&threadOrder=0-2-3-5-6-1-4 Expected results: Having developer tools open should only have a minor impact on page load performance

Several people are working on performance improvements at the moment, so hopefully the situation will be better soon. I'd like to help make this bug more actionable though, right now it's too general. Do you mind testing which of the tool makes the problem worse? Try opening the inspector first, or the console first, or debugger, etc. Depending on the result, we should move this bug under the corresponding bugzilla component.

FWIW in the profile I see stuff from netmonitor show up the most, see for example: https://perfht.ml/2i09WvM. So if I had to guess, Zac had the Network Monitor open (and if not, then this code is running without the network monitor being open which is kind of worse!) BTW, Zac, I think you have captured your profiled with a sampling frequency of 8ms which is super low. In the future, please consider setting the frequency setting to 1ms by clicking on the toolbar icon, and adjusting the Interval slider to 1ms. That will help generate more useful profiles for us. Thank you!

That specific example was with the network panel open, here are some profiles recorded at 1ms network panel open https://perf-html.io/public/447190952b29cf1a77b10b2bf3adbeb36e893213/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-1-5 debugger open https://perf-html.io/public/77e378835865ff9ca5f507e5c90a4b6c7a05d62d/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-1-6 console open https://perf-html.io/public/3d457dc95597daafe87c34b4a8a102d444feeffa/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-6-1-7 style editor open https://perf-html.io/public/090fa2b5ebb173eeb09f499bc6ffacf554485cb3/calltree/?hiddenThreads=&thread=2&threadOrder=0-2-3-4-5-6-7-1-8

Honza, are you aware of existing NetMonitor bugs about this? Are there duplicates out there? Perhaps the profile recording above is useful.

(In reply to Patrick Brosset <:pbro> from comment #4) > Honza, are you aware of existing NetMonitor bugs about this? Are there > duplicates out there? Perhaps the profile recording above is useful. It's known that the Net monitor slows down the page load. It's combination of the following things: 1) CSS re-layout is expensive and it would help to use different and faster layout for the panel content (grid, table, etc.) 2) Amount of data transferred over RDP could be yet reduced (e.g. image response bodies should not be sent) and the little image previews in the File column should not be calculated and rendered. 3) Reduce number of rendered components. E.g. by using React Virtualized (blocked by APZ), use Canvas for the waterfall graph, etc. 4) There might be some room for optimization in the reducer and ImmutableJS usage. 5) The backend should not collect any HTTP data if not necessary. Especially the #5 could help atm and I know that Alex did some analysis, Alex is there related bug report? When testing this bug I noticed significant slow down (about twice as slow) when selecting the Style Editor and switching back to the Network panel. This is surprising, not sure how much effort we put into optimizing the Style editor panel. Perhaps, there might be some quick wins? -- NetMonitor Performance Meta bug 1350969 Honza

Thank you Honza for the link to the netmonitor bug. Jason: do we have something similar for the debugger? Gabriel: for the style-editor? Brian: for the console? As I said, this is a very general bug, so if we can get more specific bugs per panel, then maybe we can make this one a [meta] and have those other ones as dependencies. Or maybe just close this one.

(In reply to Patrick Brosset <:pbro> from comment #6) > Thank you Honza for the link to the netmonitor bug. > Jason: do we have something similar for the debugger? > Gabriel: for the style-editor? > Brian: for the console? > > As I said, this is a very general bug, so if we can get more specific bugs > per panel, then maybe we can make this one a [meta] and have those other > ones as dependencies. Or maybe just close this one. We have a metabug tracking slowness by the console here: https://bugzilla.mozilla.org/show_bug.cgi?id=1156747. There's also the meta https://bugzilla.mozilla.org/show_bug.cgi?id=1125322 which this one might be a dupe of.

(In reply to Jan Honza Odvarko [:Honza] from comment #5) > (In reply to Patrick Brosset <:pbro> from comment #4) > > Honza, are you aware of existing NetMonitor bugs about this? Are there > > duplicates out there? Perhaps the profile recording above is useful. > > It's known that the Net monitor slows down the page load. > It's combination of the following things: > > 1) CSS re-layout is expensive and it would help to use different and faster > layout for the panel content (grid, table, etc.) > 2) Amount of data transferred over RDP could be yet reduced (e.g. image > response bodies should not be sent) and the little image previews in the > File column should not be calculated and rendered. > 3) Reduce number of rendered components. E.g. by using React Virtualized > (blocked by APZ), use Canvas for the waterfall graph, etc. > 4) There might be some room for optimization in the reducer and ImmutableJS > usage. > 5) The backend should not collect any HTTP data if not necessary. > > Especially the #5 could help atm and I know that Alex did some analysis, > Alex is there related bug report? I have not, but the OOM clearly highlights something wrong with the network monitor actor (bug 1297525). Did you used profiler data to come up to these conclusions? For example, if you filter with "network-monitor", you will see that it computes a lot and during the whole page load http://bit.ly/2vrjZvc This profile is against youtube.com load, with the webconsole opened. If you remove "network-monitor" filter and look at content process, you will see that network monitor is the first devtools code, then some script.js/source map code and only after that console listeners... On the parent process, new console frontend if first, by far, but network monitor is still significative here and is mosly the actor code living in parent process. We should all look at profiler results, it is quite often easily actionnable. For example there is "parseCertificateInfo" function from network-helper.js which takes 190ms, or about 25% of netmonitor codebase cost in the parent process: http://bit.ly/2vrqXAh

This is fixed on dev edition.