web-dev-qa-db-ja.com

Google Chrome Developer Toolkitが遅い

私はしばらくの間、Google Chromeの開発ツールキット（要素検査、スタックトレース、JavaScriptデバッグなど）を使用して、大きな成功を収めてきました。

しかし、約2週間前に突然、非常に低迷しました。たとえば、UIで要素を右クリックして[要素の検査]をクリックするか、F12キーを押すだけで、コードウィンドウが表示されるまで30〜45秒かかります。以前は1秒もかからなかった。

他の誰かがこの問題に遭遇しましたか？その場合、修正できましたか？どうやって？

前もって感謝します！

マット

google-chromejavascript-debugger
41
Matt Cashatt

これは、Chromeでキャッシュ（一時ファイル、Cookieなど）をクリアすることで解決しました。根本的な原因が何かはわかりませんが、それで問題が解決しました。

10
Matt Cashatt

Procmonを起動して、Chromeが実際にProjectsフォルダ全体（数十万のファイルに相当）を読み取っていた）が見られるまで、私は同じ問題を抱えており、運がなくても同じ解決策を試しました。

開発ツール設定アプリのWorkspace/Foldersセクションにそのフォルダーへの参照がありました。参照を削除すると問題が解決しました。

37
Pablo Montilla

私も同じ問題を抱えていました。

私の問題は、browserifyを使用して幅の大きなバンドル（約92,000行）のSOURCEMAPを作成することでした。 browserify app.js -d -o bundle.js。

bundle.jsを分割することで解決しました。

modules.jsを追加して、すべてのノードモジュールを別のファイル（--require [module name]）にエクスポートしました。

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

次に、bundle.jsを追加して、アウトソーシングされたモジュールなしで--external [module name]を作成します。

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

（-t babelify、私はプロジェクトでreact/JSXを使用したため。）

[〜＃〜] note [〜＃〜]：module.jsの前にbundle.jsをHTMLに含める必要があります。

私のbundle.jsは〜92000行から〜26000行に縮小されました;-)

[〜＃〜] edit [〜＃〜]：外部モジュールなしのバンドル（node_modules）を作成するには、--no-bundle-externalの代わりに[-x NODE_MODULE_NAME]*を使用することもできます。

編集＃2：多くのサブモジュールを含むプロジェクトでモジュールを使用している場合、-r|-x [MAIN_MODULE_NAME]はサブモジュールを必要としません|除外しません。

react-bootstrapの例：

react-bootstrapには、多くのサブモジュールreact-bootstrap/lib/[submodule]が含まれています。

browserify -r react-bootstrap > build/modules.jsは、たとえばButton（react-bootstrap/lib/Button）モジュールを必要としません。そう...

...使用している場合

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

...--no-bundle-externalはallサブモジュールを含むノードモジュールを除外するため、アプリでButtonを使用することはできません。したがって、次のことを行うために必要なすべてのサブモジュールを要求することを忘れないでください。

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

[〜＃〜] note [〜＃〜]：さらに、パフォーマンスを向上させるために、exorcistを使用してソースマップを別のファイルに入れることができます。それをインストールします：

npm install --save-dev exorcist

browserifyコマンドを変更します。

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

smhgに感謝excorcistのヒント。詳細については、彼の回答を表示してください。

4
marcel

Chrome 46.x/47.x）を使用すると、提案されたソリューションはどれも機能しませんでした。何がdidブラウザーの詳細設定で、「可能な場合はハードウェアアクセラレーションを使用する」という設定を無効にする作業でした。

プロセスモニター/リストで、Chromeレンダラーが大量のCPUを使用しており、上記のように、ブレークポイントを挿入したり、デバッガーにステートメントをステップ実行したりする場合でも、10秒以上かかることがわかりました。

3
AsGoodAsItGets

marcelの回答にコメントとして追加しましたが、それは私にとって非常に大きな違いを生んだので、置く価値はあると思います別の答えとして：

合計サイズが約2〜3MBのファイルにインラインJSソースマップがありました（開発中は非圧縮）。 Chrome開発者ツールを開いた状態で、ページの読み込みが耐えられないほど遅くなりました。）約20秒後、ファイルとインラインソースマップが解析されると、状況はおおむね正常になります。さらに、 Chrome 43（Ubuntu））へのアップデートでさらに悪い。

ソースマップを別のファイルに入れるとすぐに、すべてが正常に戻りました。ページ読み込みの速度低下はなくなりました。ソースはすぐに利用できます。

私はbrowserifyでビルドしているので、 exorcist を使用しました。より具体的に： この問題 で説明されているように、-oパラメータにwatchifyを使用します。

2
smhg

私の解決策は、コンピューター上でローカルに実行されていて、IISに接続されているプロジェクトのバッチを削除することでした。フォルダーやプロジェクトを削除しただけで、あまり使用しなくなった。 25GBのデータが削除され、私の開発ツールバーが魅力的に機能するようになりました！

1
Chris Heijnen

私はこのような問題を抱えていました。デバッガーウィンドウを開くのが遅い（10〜20秒）だけでなく、コードをステップオーバーするたびに、どれほど単純なことでも、長い遅延（10〜20秒）が発生しました。

私の原因は、スコープ内にいくつかの大きな配列（1000エントリ、数10 MBのデータ）があったことです。デバッガーは、「スコープ変数」ウィンドウに表示するために、スコープ内のすべてのデータ（すべてのグローバル、Windowにぶら下がっているすべて、および呼び出しスタックのすべての関数へのすべてのパラメーターを含む）を事前レンダリングします。データのツリーが大きい場合、変数検査ツリーを再計算するためにデバッガーに長い時間がかかります。

（a）大きな配列を非グローバルスコープに移動し、それがWindowから外れるようにしてから、（b）残りのプログラムを別のスコープに移動することで、問題を回避できました。そのようです：

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

残念ながら、大きな配列を参照するコードをステップ実行する必要がある場合、回避策はありません。

1
Zero Trick Pony

キャッシュとすべてのプライバシーデータをクリアすると、私の問題も解決しました:-)

0
Shashank Agarwal

これは将来のバージョンで修正されます： https://code.google.com/p/chromium/issues/detail?id=485052

0
Hulvej

ソースマップを含む私の変換されたファイルは約5MBです。私はこの投稿ですべての解決策を試しましたが、わずかな改善しか見ていません。私は結局諦め、アンインストールしてChromeを再インストールしました。すぐにそれができたら、デバッガーでのソースマップの読み込みは約15秒から3になりました。

0
app_sciences