Google Chrome Developer Toolkit is Slow

StackOverflow https://stackoverflow.com/questions/8125006

  •  28-02-2021
  •  | 
  •  

Question

I have been using Google Chrome's dev tool kit (element inspection, stack trace, javascript debugging, etc.) for some time with great success.

However, about two weeks ago, it suddenly became VERY sluggish. For example, when I right-click an element in the UI and then click "Inspect Element", or when I simply press F12, the code window takes 30-45 seconds to come up. It used to happen in less than a second.

Has anyone else run into this problem? If so, were you able to correct it? How?

Thanks in advance!

Matt

Was it helpful?

Solution 2

This was solved by clearing my cache (temp files, cookies, etc) in Chrome. Not sure what the root cause was, but that fixed the problem.

OTHER TIPS

I've had the same problem, tried the same solutions without luck, until I fired procmon and saw that Chrome was actually reading my entire Projects folder (which is several hundred thousand files worth).

There was a reference to that folder in the Workspace/Folders section in the dev tools Settings app. Removing the reference solved the problem.

I have had the same problem.

My Problem was, that i used browserify to create a large bundle (~92k lines) width SOURCEMAP. browserify app.js -d -o bundle.js.

I solved it by splitting my bundle.js.

I exported all node modules into a seperate file (modules.js) by adding --require [module name]:

browserify -r react -r lodash -r three > build/modules.js

and then create the bundle.js without the outsourced modules by adding --external [module name].

browserify -t babelify -x react -x lodash -x three src/app.js > build/bundle.js

(-t babelify, because i used react/JSX in my project.)

NOTE: You have to include module.js in your html before bundle.js.

My bundle.js shrinked from ~92000 to ~26000 lines ;-)

EDIT: To create a bundle without external modules (node_modules) you can also use --no-bundle-external instead of [-x NODE_MODULE_NAME]*.

EDIT #2: When you are using an module in your project that contains many submodules, -r|-x [MAIN_MODULE_NAME] won't require|exclude the submodules.

Example with react-bootstrap:

react-bootstrap contains many submodules, react-bootstrap/lib/[submodule].

browserify -r react-bootstrap > build/modules.js won't require for example the Button (react-bootstrap/lib/Button) module. So...

...if you are using

browserify --no-bundle-external src/app.js > build/bundle.js

...you wont't be able to use Button in your app, because --no-bundle-external excludes all node modules, including submodules. So don't forget to require all necessary submodules to:

browserify -r react-bootstrap -r react-bootstrap/lib/Button > build/modules.js

NOTE: Additionally, to increase the performance you can use exorcist to put the sourcemap into a separate file. Install it with:

npm install --save-dev exorcist

and change your browserify command:

browserify --no-bundle-external src/app.js | exorcist build/bundle.js.map > build/bundle.js

Thanks to smhg for the hint with excorcist. And show his answer for more details.

Using Chrome 46.x/47.x on Linux (RHEL 7), none of the proposed solutions worked for me. What did work was to disable the setting "Use hardware acceleration when available", in the advanced browser settings.

I noticed in the process monitor/list that the Chrome renderer was taking up a lot of CPU and as described above, even putting a breakpoint or stepping throught statements in the debugger would take 10+ seconds!

I've added it as a comment to marcel's answer, but since it made such a big difference for me I think it is worth to put it as a separate answer:

I had an inline JS source map in a file with a total size of about 2-3MB (uncompressed, during development). Chrome was unbearably slow on page loads (with Developer Tools open). After about 20 seconds, when the file and inline source map were parsed, things would be more or less normal. Additionally, it got worse with the update to Chrome 43 (on Ubuntu).

As soon as I put the source map in a separate file, everything went back to normal. The slowdown on page load is gone. Sources are available instantly.

Since I build with browserify, exorcist was what I used. More specifically: with watchify in the -o parameter as described in this issue.

I had a problem like this; opening the debugger window was sluggish (10-20 seconds) and also every time I stepped over code, no matter how simple, I experienced a long delay (10-20 seconds).

The cause for me was that I had some large arrays (1000s of entries, 10s of MB of data) in scope. The debugger pre-renders all in-scope data (including all globals, everything hanging off Window, and all parameters to all functions on the call stack) for display in the "Scope Variables" window. If that tree of data is large, then each step it will take the debugger a long time to recalculate the variable inspection tree.

I was able to work around the problem by (a) moving the large array into a non-global scope, to keep it off of Window, and then (b) moving the rest of my program into a separate scope. Like so:

<script>
(function() {
  // large variable in stack scope, stepping in any
  // code called from here will be slow
  var hugeArray = [...];
  calculateHugeArray(hugeArray);
})();

(function() {
  // large variable now out of scope, so Chrome won't
  // try to display it in the "Scope Variables"
  // window. This makes debugging and stepping faster.
  doMoreThings();
})();
</script>

Unfortunately if you need to step through code that references the large array, then I don't have a workaround.

My solution was to just delete a batch of projects that were running locally on my computer and were connected to IIS. Just removed folders/projects i don't use a lot or anymore. removed 25GB of data and now my dev toolbar works like charm!

Clearing cache and all privacy data solved my problem as well :-)

My transpiled file including source map is about 5MB. I have tried all of the solutions in this post and have only seen marginal improvement. I eventually gave up and uninstalled and reinstalled Chrome. Wish I did that right away, my source map load in the debugger went from about 15 seconds to 3.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top