web-dev-qa-db-fra.com

Google Chrome Developer Toolkit est proposé

J'utilise le kit d'outils de développement de Google Chrome (inspection d'élément, trace de la pile, débogage de javascript, etc.) avec un grand succès.

Cependant, il y a environ deux semaines, cela est devenu soudainement TRÈS lent. Par exemple, lorsque je clique avec le bouton droit de la souris sur un élément de l'interface utilisateur, puis que je clique sur "Inspecter l'élément", ou que j'appuie simplement sur F12, la fenêtre de code prend 30 à 45 secondes pour s'afficher. Cela se passait en moins d'une seconde.

Quelqu'un d'autre a-t-il rencontré ce problème? Si oui, avez-vous pu le corriger? Comment?

Merci d'avance!

Mat

google-chromejavascript-debugger
41
Matt Cashatt

Cela a été résolu en effaçant mon cache (fichiers temporaires, cookies, etc.) dans Chrome. Je ne sais pas quelle était la cause première, mais cela a résolu le problème.

10
Matt Cashatt

J'ai eu le même problème, essayé les mêmes solutions sans succès, jusqu'à ce que je lâche Procmon et voie que Chrome lisait réellement tout mon dossier Projects (ce qui représente plusieurs centaines de milliers de fichiers). 

Il y avait une référence à ce dossier dans la section Espace de travail/Dossiers de l'application Paramètres des outils de développement. Supprimer la référence a résolu le problème.

37
Pablo Montilla

J'ai eu le même problème. 

Mon problème était, que j'ai utilisé browserify pour créer un grand paquet (~ 92k lignes) largeur SOURCEMAP. browserify app.js -d -o bundle.js. 

Je l'ai résolu en divisant mon bundle.js. 

J'ai exporté tous les modules de nœud dans un fichier séparé (modules.js) en ajoutant --require [module name]:

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

puis créez le bundle.js sans les modules externalisés en ajoutant --external [module name].

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

(-t babelify, car j’ai utilisé react/JSX dans mon projet.)

NOTE: Vous devez inclure module.js dans votre code HTML avant le bundle.js.

Mon bundle.js est passé de ~ 92000 à ~ 26000 lignes ;-)

EDIT: Pour créer un ensemble sans modules externes (node_modules), vous pouvez également utiliser --no-bundle-external au lieu de [-x NODE_MODULE_NAME]*. 

EDIT # 2 : Lorsque vous utilisez un module dans votre projet contenant de nombreux sous-modules, -r|-x [MAIN_MODULE_NAME] ne nécessite pas d'exclure les sous-modules. 

Exemple avec react-bootstrap:

react-bootstrap contient de nombreux sous-modules, react-bootstrap/lib/[submodule].

browserify -r react-bootstrap > build/modules.js ne nécessitera pas par exemple le module Button (react-bootstrap/lib/Button). Alors...

... si vous utilisez

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

... vous ne pourrez pas utiliser Button dans votre application, car --no-bundle-external exclut les modules all node, y compris les sous-modules. Alors n'oubliez pas d'exiger tous les sous-modules nécessaires pour:

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

NOTE: De plus, pour augmenter les performances, vous pouvez utiliser exorcist pour placer le plan source dans un fichier séparé. Installez-le avec:

npm install --save-dev exorcist

et changez votre commande browserify:

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

Merci à smhg pour l'indice avec excorcist. Et montrez sa réponse pour plus de détails.

4
marcel

En utilisant Chrome 46.x/47.x sous Linux (RHEL 7), aucune des solutions proposées ne fonctionnait pour moi. Ce que a fait a donc été de désactiver le paramètre "Utiliser l’accélération matérielle lorsque celle-ci est disponible" dans les paramètres avancés du navigateur.

J'ai remarqué dans la liste des surveillants de processus que le moteur de rendu Chrome prenait beaucoup de temps processeur et que, comme décrit ci-dessus, même mettre un point d'arrêt ou exécuter des instructions pas à pas dans le débogueur prendrait plus de 10 secondes!

3
AsGoodAsItGets

Je l'ai ajouté en tant que commentaire à la réponse de marcel , mais comme cela a fait une si grande différence pour moi, je pense que cela vaut la peine de l'exprimer séparément:

J'avais une carte source JS en ligne dans un fichier d'une taille totale d'environ 2-3 Mo (non compressée, au cours du développement). Le temps de chargement de Google Chrome était insupportablement lent (avec les outils de développement ouverts). Après environ 20 secondes, lorsque le fichier et la carte source intégrée ont été analysés, les choses étaient plus ou moins normales. De plus, la mise à jour de Chrome 43 (sur Ubuntu) a empiré.

Dès que j'ai placé la carte source dans un fichier séparé , tout est rentré dans l'ordre. Le ralentissement du chargement de la page est parti. Les sources sont disponibles instantanément.

Depuis que je construis avec browserify, exorcist était ce que j’utilisais. Plus précisément: avec watchify dans le paramètre -o comme décrit dans this issue .

2
smhg

Ma solution consistait simplement à supprimer un lot de projets qui s'exécutaient localement sur mon ordinateur et qui étaient connectés à IIS. Je viens d’enlever des dossiers/projets que je n’utilise pas beaucoup ou plus. supprimé 25 Go de données et maintenant ma barre d'outils dev fonctionne comme un charme!

1
Chris Heijnen

J'ai eu un problème comme ça; ouvrir la fenêtre du débogueur était lent (10 à 20 secondes) et chaque fois que je franchissais le code, peu importe sa simplicité, je ressentais un long délai (10 à 20 secondes).

La cause pour moi était que j'avais de grands tableaux (1 000 entrées, 10 Mo de données) dans la portée. Le débogueur effectue préalablement le rendu de toutes les données incluses dans la portée (y compris toutes les valeurs globales, tout ce qui est suspendu à Window et tous les paramètres de toutes les fonctions de la pile d'appels) pour affichage dans la fenêtre "Variables de portée". Si cette arborescence de données est volumineuse, le débogueur met ensuite longtemps à recalculer l’arbre d’inspection des variables.

J'ai réussi à contourner le problème en (A) en déplaçant le grand tableau dans un périmètre non global, afin de le garder en dehors de Window, puis en (B) en déplaçant le reste de ma liste. programme dans un champ séparé. Ainsi:

<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>

Malheureusement, si vous devez parcourir le code qui référence le grand tableau, je n'ai pas de solution de contournement.

1
Zero Trick Pony

Effacer le cache et toutes les données de confidentialité ont également résolu mon problème :-)

0
Shashank Agarwal

Ceci est résolu dans une future version: https://code.google.com/p/chromium/issues/detail?id=485052

0
Hulvej

Mon fichier transpilé, y compris la carte source, fait environ 5 Mo. J'ai essayé toutes les solutions de ce post et n'ai constaté qu'une amélioration marginale. J'ai finalement abandonné et désinstallé et réinstallé Chrome. Si seulement je pouvais le faire tout de suite, le chargement de la carte source dans le débogueur est passé d’environ 15 secondes à 3 secondes. 

0
app_sciences