こんにちは、Copilot を並走させて画面ごと止めてしまったアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
TL;DR
- この調査は進行中です。根本原因はまだ特定できていません。 続報が出たら追記または続編を書きます。
- 重い GitHub Copilot Agent 作業を 2 つの VS Code ウィンドウで並走させると、私の Windows 環境ではマウスやウィンドウ切り替えを含む画面描画が著しく重くなりました。
- ログから、OS 全体の CPU / RAM / disk、GPU とデスクトップ描画、Microsoft Scout、Git status 単体は主因として後退しました。優先調査対象は VS Code 内部の UI 処理経路と、その上で動く長い Chat・tool output の処理です。
-
chat.agent.maxRequestsを1000から100に下げて一定期間使いましたが、UI 遅延は再現しました。Agent が頻繁に続行確認で止まり実用性も下がったため、現在は1000に戻しています。
読者が最初に試せる切り分けは、重い Agent 作業の並走を止め、1 本ずつ実行して症状が変わるか確認することです。この記事を根拠に、maxRequests、履歴要約、debug logging、watcher の除外設定を一括変更しないでください。WPR は今回の調査で使用した計測手段であり、全読者への必須手順ではありません。
現時点の仮説と未確認範囲
chat.agent.maxRequests=1000 が原因だった可能性は、かなり下がりました。100 へ下げても同じ UI 遅延が再現し、変わったのは Agent が早めに続行確認で止まることだったためです。現行実装でも、この設定は Agent の並列度、CPU 使用率、画面更新頻度を直接変えません。作業継続性を優先し、現在は 1000 に戻しています。
WPR では、VS Code の画面やウィンドウ管理を担う中心プロセスが継続して CPU を使っていました。ただし、この活動が UI 遅延の原因かはまだ分かっていません。次は保存済みの計測データを使い、症状中に VS Code 本体が何を実行し、何を待っていたかを調べます。
今回の調査では、GitHub Copilot CLI に切り分け案を考えさせ、PowerShell の収集スクリプトも作らせながらログを分析しました。最後に /share gist でセッション全体を GitHub Gist に保存し、その記録を検索・再読しながらこの記事を書いています。これは私自身が実行した手順です。Gist の URL と生ログは記事には載せず、公開できる観測結果だけに絞ります。
この記事の数値は、診断ワークスペースに保存した各 Run のログ、分析ノート、Copilot CLI のセッション記録を突き合わせた結果です。WPR で保存した元の計測データや環境固有情報は公開していないため、第三者が同じ数値を再計算できる公開データではありません。そこで、測定区間・収集間隔・別 Run 間を直接比較できない点も本文に併記します。
起きたこと: 画面描画が止まるほど重い
別々の VS Code ウィンドウで、サブエージェントや PowerShell を使う重い GitHub Copilot Agent 作業を同時に進めていました。私の環境では、開始からおよそ 1 分を過ぎたあたりで次の症状が出ました。
- マウスポインターの移動が重い
- アクティブウィンドウの切り替えが遅い
- VS Code だけでなく、端末全体の操作がもたつく
この「約 1 分」は今回の条件での観測時刻です。すべてのワークスペース、モデル、Agent 作業に共通する閾値ではありません。
最初は「CPU かメモリが埋まったのかな」と思いました。ところが、ログを重ねるほど単純な資源不足では説明できなくなりました。
先に残った被疑箇所
詳細な調査過程へ入る前に、現時点の結論を並べます。設定値と実際に動いている処理は分けて評価しています。
この記事に出てくる VS Code 内部のプロセスは、次の役割です。
| 記事内の表記 | 役割 |
|---|---|
| main process | VS Code 全体と各ウィンドウを取りまとめる中心処理 |
| renderer | 各ウィンドウの画面表示や入力を扱う処理 |
| Extension Host | Copilot などの拡張機能を動かす処理 |
| GPU process | 画面描画の一部を GPU へ渡す処理 |
どのプロセスが原因かは、まだ特定できていません。
| 疑い | 現在の強さ | 根拠と限界 |
|---|---|---|
| VS Code 本体・画面表示・プロセス間の連携 | 次に詳しく確認する対象 | WPR で main process の継続的な CPU 活動を観測。ただし、どの内部処理が UI 遅延につながったかは未確認 |
| 長い Chat 状態、tool output、terminal 取り込み | 中程度 | 類似 Issue があり、重い Agent 作業と条件が合う。今回と同じ stack は未確認 |
| 拡張機能側の Chat 状態処理 | 中程度 | 類似 Issue はあるが、今回の症状中に同じ処理が動いていたかは未確認 |
| workspace 探索 / watcher / SCM | 弱い・一部反証あり | 大規模 workspace だが、持続する rg 高負荷や遅い Git status は未確認 |
| GPU / DWM 飽和 | 弱い・反証あり | 症状区間の対象 GPU は低く、GPU Hardware Queue の持続的な詰まりも未検出 |
| Defender / EDR / GSA | 未観測 | 原因にも無関係とも言えないが、今回のログでは相関を確認していない |
4 回の別 Run で後退した候補、次に stack 付きで確認する対象、maxRequests=100 の検証結果を 1 枚にまとめました。
GitHub Copilot CLI と一緒に診断環境を作った
今回、私が最初から PowerShell の診断スクリプトを書いたわけではありません。症状、再現条件、手元にあった診断資材を GitHub Copilot CLI へ渡し、まず「再現前に何を準備すべきか」を考えてもらいました。
最初に作ったのは、トラブルシューティング専用の作業フォルダーです。元の診断資材を変更せずに保管し、次のものを分けました。
- 原本を置く場所
- 実際に変更する診断ツールの作業コピー
- 再現手順と判断基準
- 取得したログ
- 分析結果と未確定事項
ログを取るだけなら、その場限りの PowerShell でもできます。しかし、再現を何度か試すうちに「どの試行のログか分からない」「症状が出た時刻と数字が結び付かない」「収集スクリプト自身が負荷を増やす」という問題が出ます。そこで Copilot CLI に、診断そのものを小さなプロジェクトとして管理させました。
最初のラバーダックで計画の穴が見つかった
初期計画をラバーダックでレビューすると、再現前に直すべき点が出てきました。
- Scout のプロセス名が収集対象に入っていない可能性がある
- 固定 10 分のトレースでは、発症前に収集が終わる可能性がある
- 実行 ID がなく、どの設定・症状・ログが同じ試行か追えない
- 本番の再現時にカウンター取得自体が失敗する恐れがある
この指摘を受けて、Copilot CLI にプリフライトと実行単位の識別を追加させました。再現前の短時間テストでは、システム行 2、Scout 関連行 8、収集失敗 0 を確認してから本番へ進んでいます。
最初から重い WPR を回さなかったのも、この計画で決めたことです。まず軽いカウンターで大きな資源枯渇を探し、それで説明できなければ取得範囲を狭める。それでも足りない場合だけ WPR を使う順番にしました。
対話しながらスクリプトを増やした
提供済みの診断資材を作業コピーへ分離したうえで、Copilot CLI に追加・改善させた主なスクリプトは次のとおりです。
| スクリプト | 役割 | 追加した理由 |
|---|---|---|
Start-ReproductionPreflight.ps1 |
短時間の snapshot と trace を実行し、収集可否を確認 | 本番再現後に「ログが取れていなかった」を避ける |
Start-ReproductionTrace.ps1 |
CPU、memory、disk、paging、関連プロセスを一定間隔で保存 | 最初に OS 全体の資源枯渇を確認する |
Start-UiResponsivenessCapture.ps1 |
Code、WebView、DWM、Scout の CPU / GPU を集中取得 | 全体負荷では説明できなかった UI 遅延を追う |
Mark-SymptomStart.ps1 / Mark-SymptomEnd.ps1
|
症状の開始・終了を 1 行の時刻として記録 | 体感とログを同じ時間軸へ載せる |
Capture-VSCodeRuntimeSummary.ps1 |
VS Code のプロセス種別ごとの CPU / memory を匿名化して集計 | 生のコマンドラインやワークスペース名を残さず、main / renderer / Extension Host を見る |
コードを生成して終わりにはせず、各スクリプトについて構文確認または対象に応じた短時間スモークテストと出力確認を Copilot CLI に実行させました。失敗したら、そのログを読ませて同じスクリプトを修正しています。
5 段階で切り分けた結果
ここまでの取得結果は、同じ 1 回の再現を段階的に測ったものではありません。公開用に実際の RunId を一般化すると、次の 4 試行です。
| 試行 | 症状マーカー | 収集方法 | 主な用途 |
|---|---|---|---|
| Run A | 後から体感時刻を確認 | 5 秒の待機を設定した軽量トレース | OS 全体の CPU / memory / disk と関連プロセスを見る |
| Run B | 症状なし | 初期版の UI/GPU キャプチャ | 無症状時との比較、収集ツール自身の負荷を発見する |
| Run C |
SymptomStart あり |
軽量化後の対象プロセス別 UI/GPU キャプチャ | 症状区間の Code / WebView / DWM / Scout を見る |
| Run D | 厳密なマーカー区間あり | WPR / ETW | Code のプロセス別 CPU、scheduler、GPU queue を見る |
試行をまたいだ数字は、そのまま性能差として比較していません。各試行で「その原因候補が症状全体を説明できるか」を確認しています。
1. 実効約 5.9 秒間隔の軽量トレース（Run A）
最初の再現では、6 分 41 秒にわたって 69 サンプルを取得しました。
- システム CPU: 平均 約 21%、最大 約 55%
- 空きメモリ: 最低でも 約 25 GB
- commit（仮想メモリの確保量）使用率: 約 48%
- disk I/O / paging: 持続的な飽和なし
- Scout: 持続的な高負荷なし
5 秒の待機を設定した収集ですが、取得処理を含む実効間隔は約 5.9 秒でした。これで「OS 全体の CPU や RAM が埋まり続けた」という見方は弱まりましたが、短いスパイクや UI スレッドの停止は見逃します。
このトレースには WebView2 の大きな単発スパイクもありました。私は一瞬「WebView が原因では？」と思いましたが、ラバーダックは、スパイクが症状開始より後であり、開始後ずっと続いた UI 遅延を 1 回のピークでは説明できないと指摘しました。system CPU と process CPU も収集タイミングが異なるため、同じ時刻の値を単純比較できません。
この指摘で、WebView2 を「主因」から「一時的に悪化させた可能性がある候補」へ戻しました。Copilot CLI で大きな数字を抽出し、別モデルのラバーダックに時系列と持続時間を反証させたことで、観測事実と推測を分けやすくなりました。
2. UI / GPU へ絞った再現（Run C）
次は症状開始後の約 71 秒、34 サンプルを取りました。
- システム CPU: 平均 約 23%
- Code / WebView の対象 GPU: 症状区間では 0%
- DWM GPU: 最大 約 3%
- Scout: 引き続き低負荷
DWM は Windows のデスクトップ描画を合成するプロセスです。この区間では GPU / DWM の飽和が見えず、描画の重さを GPU 使用率だけで説明するのは無理がありました。
Run C の「対象 GPU 0%」は、プロセスを絞り、1 秒の待機を設定したカウンター要約です。取得処理を含む実効間隔は約 2.15 秒で、その間の短い GPU スパイクは否定できません。後述する Run D の「GPU 実行率 0.46%」は ETW の GPU 実行イベントから求めた別の指標であり、同じ測定値の前後比較ではありません。
初回ログでは「開始から約 1 分後に重くなった」という記憶しかなく、6 分ぶんの数字から都合のよいピークを拾う危険がありました。そこで SymptomStart と SymptomEnd を markers.csv へ 1 行ずつ記録するスクリプトを追加しています。Run C では SymptomStart からキャプチャ終了までの約 71 秒を症状区間として扱いました。
このマーカーがあったことで、症状中の GPU 使用率が低いことと、症状なしでも CPU が高い Run B を別の条件として扱えました。
3. 症状なしでも CPU は高かった（Run B）
別の試行では、CPU が平均 約 48%、一時 100% まで上がったのに、画面は重くなりませんでした。このログは収集側の負荷も混ざっているため CPU 値の直接比較には使えませんが、少なくとも「CPU が高い = 今回の UI 遅延」とは言えません。
調べると、初期版は Windows の GPU Engine カウンターを毎回全件列挙していました。全件取得は 1,171 行で約 3.4 秒、対象となる 91 PID だけへ絞ると 218 行で約 1.2 秒でした。さらにプロセス単位の要約へ変更し、10 秒のスモークテストでは 6 サンプル、GPU 要約 96 行、全体約 74 KB に収めています。
性能調査では、収集処理自身の負荷も交絡要因になります。Copilot CLI にスクリプトを書かせるだけでなく、短時間のスモークテストと出力サイズ確認まで実行させ、観測方法を軽量化しました。
4. WPR では VS Code 本体の処理が続いていた（Run D）
最後に Windows Performance Recorder（WPR）で、Windows の処理を時系列に記録しました。全体は 101.30 秒で、厳密に症状時刻を付けた区間は 20.36 秒です。マーカー前も体感上は重い状態でした。
症状区間では、VS Code の中心プロセスが約 0.90 論理コア分を継続使用し、画面表示に関わる処理も同時に動いていました。これは最後の 20 秒だけの一時的な山ではありませんでした。ただし、どの内部処理が原因かはまだ特定できていません。
GPU 側も確認しました。症状と重なる区間の GPU 実行率は約 0.46%で、GPU 処理の送信から完了までの時間も最大 2.33 ms でした。この区間では、GPU の処理待ちが長く続いた形跡はありませんでした。
確認できたのは、VS Code 本体が継続して CPU を使っていたことまでです。それが UI 遅延の原因か、本体・画面表示・拡張機能・プロセス間の連携のどこで待ちが増えたのかは未確定です。
5. ワークスペースと Git も確認した
2 つのワークスペースは、どちらも未コミット変更がある状態でした。大きい方は約 4.1 万ファイルあり、files.watcherExclude と search.exclude は未設定でした。
ただし、Git の状態取得はそれぞれ約 164 ms と約 91 ms、変更件数は 20 件と 29 件でした。少なくとも git status 単体が数秒間詰まっていたわけではありません。大きい ignored 領域の探索や watcher は短い増幅要因として残りますが、主因の疑いは下がっています。
匿名化した実行状況から、各ウィンドウの画面表示、拡張機能、ファイル監視が動いていることは確認しました。ただし、症状が再発した瞬間の記録ではないため、どの処理が UI を止めたかは判断できません。
maxRequests=100 でも再現した
設定候補の中で、最初に chat.agent.maxRequests だけを変更して一定期間使いました。結果は次のとおりです。
| 観点 |
100 で使った結果 |
判断 |
|---|---|---|
| UI 遅延 | 重い Agent 作業中に再現した |
maxRequests=1000 は主因ではなさそう |
| Agent の継続性 | 続行確認で比較的早く止まる | 長い作業では運用コストが高い |
| CPU / 並列度 | この設定では直接制御しない | UI 遅延の直接対策にはならない |
| 現在値 |
1000 に戻した |
作業継続性を優先する |
この結果から、maxRequests は主因候補と緩和策の両方から外します。少なくとも私の環境では、100 は重さを直さず、Agent を早く止める設定として働きました。
調査の途中で、VS Code のユーザー設定に次が入っていることを確認しました。
"chat.agent.maxRequests": 1000
chat.agent.maxRequests は、Agent が 1 ターンでユーザー確認を求めるまでに許す request 数の上限です。検証した VS Code 1.128.0 の公開ソースには、次の説明があります。
The maximum number of requests to allow per-turn when using an agent. When the limit is reached, will ask to confirm to continue.
同じ公開ソースでは、通常の VS Code ウィンドウは実験値が配布されていればその値、なければ 50、専用の agentsWindow では 1000 と定義されています。ここで重要なのは、1000 は CPU 使用率や Agent の並列数を直接指定する設定ではないことです。
| 値 | 直接変わるもの | 直接は変わらないもの |
|---|---|---|
chat.agent.maxRequests |
1 ターンで確認前に続けられる request 数 | 同時実行する Agent 数、ツール実行の並列度、CPU 使用率 |
調査時点では、通常の Agent 作業にも 1000 を明示設定していました。その後 100 へ下げて使いましたが、UI 遅延は再現しました。100 では 100 request に達した時点で続行確認が入り、長い Agent 作業が比較的早く止まります。確認後に続行すれば同じターンは続くため、設定だけで処理量が必ず減るわけでもありません。
100 は今回の UI 遅延を直す値ではありませんでした。Agent の停止頻度が上がる一方で症状は再現したため、現在は 1000 に戻しています。これは 1000 を推奨値とする意味ではなく、原因調査と Agent の継続性を分けて考えた運用判断です。
ほかの設定候補はまだ未検証ですが、現時点で設定をさらに一括変更する予定はありません。次は保存済みの計測データから VS Code 本体の処理を調べます。
類似 Issue から切り分け軸を作る
類似する公開 Issue を探すと、「Copilot が重い」という 1 つの話ではありませんでした。Agent と Chat 状態、Agent が扱うツール出力、ワークスペース側の処理に分けて見ると、次の切り分け軸が見えてきます。
| 層 | 公開 Issue | 今回と重なる観測 | 今回では未確認の点 | 原因扱いしない理由 |
|---|---|---|---|---|
| request 上限 | #256088 | 上限で「Continue to iterate」を挟み、Agent の継続を利用者が制御する設計 | 性能改善との関係 | UI 性能 Issue ではなく、暴走防止と利用者制御の機能 |
| 長い Agent / Chat 状態 | #317319 | 長期 Agent セッション中に Copilot Chat が Extension Host の CPU profile に現れた利用者報告 | 同じ関数、トークン数、Extension Host profile | 最小再現と今回と同じ環境条件は未確認 |
| 長い Chat の描画 | #297349 | 会話が長くなるほどクリック、スクロール、入力が遅くなる利用者報告 | DOM 数、renderer profile、Chat 要素ツリー | DOM が原因という投稿者仮説だけでは足りない |
| Agent の tool output / renderer | #307723 | Autopilot mode の Agent が gh コマンドを実行した際に、VS Code が応答不能になった利用者報告 |
terminal 出力の量、renderer stack、shell integration | 追加情報を求める info-needed の後に close され、修正確認はない |
| Copilot Chat 利用中の UI freeze | #316183 | Copilot Chat 利用中に VS Code 全体が応答不能になった利用者報告 | Windows での同一再現、共有プロセスの挙動 | 追加情報を求める info-needed の後に close され、原因未確定 |
| workspace 探索 | #311736 | custom agent 探索に関連すると報告された rg の CPU スパイク |
症状時の rg、探索対象、実行時間 |
別 Issue の重複として終了し、今回は rg を未観測 |
| file watcher | #305923 | 大規模 repo で特定の watcher 除外パターン評価が遅くなった closed Issue | 現行版の watcher trace、イベント数 | 今回の除外未設定を補強する根拠ではなく、今回の環境との一致も未確認 |
これらは今回の原因を裏付ける証拠ではありません。次にどこを分けて観測するかの地図です。
古い microsoft/vscode-copilot-release の Issue も検索には出てきますが、このリポジトリは現在アーカイブ済みで read-only です。README はフィードバックを microsoft/vscode へ移すよう案内しています。旧 Issue は過去の事例を読むためだけに扱います。
現時点の原因考察
私のログだけで確定したことは「2 本の重い Agent 作業と UI 遅延が同時に起きた」ことです。まだ確定していない部分を含めると、調べる順番は次のようになります。
この図の矢印は原因を示していません。今回の再現で同時に活動し得る経路と、次回に分けて観測したい対象を整理したものです。
特に確認したいのは次の 4 つです。
- Extension Host: Chat 履歴、トークン集計、Agent の状態更新で CPU を使っていないか。
- main process / renderer: Chat の描画、入力、ウィンドウ切り替えが詰まっていないか。
- tool output: 大きい PowerShell、Git、検索、テスト結果を Chat に取り込むときに遅延が増えていないか。
- workspace 処理: 大きい生成物、ローカルプロファイル、Git 管理対象外の領域まで watcher や検索が広がっていないか。
VS Code 公式の Performance Issues ガイドも、Process Explorer、code --status、Extension Host CPU profile、renderer の DevTools profile、shared process profile を分けて採る流れを案内しています。CPU の総量だけで判断しないための、まっとうな診断順序ですね。
次は保存済みのデータで VS Code 本体を調べる
maxRequests=100 の比較は終わりました。次に必要なのは、設定変更ではなく、症状中に VS Code 本体のどの処理が動き続けていたかを確認することです。
| 次に比べるもの | 確認したいこと |
|---|---|
| VS Code 本体 | 症状中に何を実行し、何を待っていたか |
| 画面表示側 | Chat の描画や入力処理が集中していなかったか |
| 拡張機能側 | Copilot やほかの拡張機能が主な負荷だったか |
必要な記録は既存データに残っています。ただし、内部の処理名を読める状態にはまだできていません。データが足りないのではなく、VS Code 本体のどの処理かを読み解く段階です。
したがって、新しい WPR はまだ取りません。既存データで判断できなければ、その時点で VS Code 標準のプロファイラーへ切り替えます。
今はやらないこと
原因がまだ VS Code のどの経路か分からない段階で、次の変更はしません。
- Microsoft Defender の除外設定
- GPU ドライバーの変更
- 大きな設定の一括変更
- 監視対象を増やすためだけの常時 ETW / WPR 収集
いずれも副作用が大きく、今のログは主要因として指していません。Defender、GPU driver、描画スタックに一貫した相関が見えてから、隔離した比較環境で検討します。
GitHub Copilot CLI を診断補助として使った
今回あらためて、GitHub Copilot CLI はトラブルシューティングと相性がよいと感じました。端末、ファイル、ログ、スクリプトを同じセッションで扱えるため、調査の流れを途中で切らずに進められます。
私が実際に頼んだ順番は、だいたい次のとおりです。
- 症状と再現条件を説明し、まだ原因を決めずに調査計画を作らせる
- 既存の診断資材を読ませ、原本を変更しない作業コピーを作らせる
- 本番前のプリフライトと短時間スモークテストを作らせる
- 再現時刻を残すマーカーと、必要最小限の収集スクリプトを作らせる
- 症状区間と無症状区間を比較させる
- 大きな数値を見つけても原因へ昇格させず、ラバーダックに反証させる
- 分かったこと、否定できたこと、未確認事項を Markdown へ残させる
最初の依頼では、次のように「原因をまだ決めない」と明示すると進めやすいです。
この症状を再現して原因を切り分けたいです。
いきなり設定変更や除外設定をせず、まず観測計画を作ってください。
収集処理自身の負荷と、ログに残る機密情報も確認してください。
分かったこと、反証されたこと、未確認事項を分けて記録してください。
ログを取った後は、数字を要約させるだけでなく、次の問いも入れると効きます。
このログで原因と言えることは何ですか。
症状の開始から終了までを説明できない単発スパイクは、主因にしないでください。
収集間隔で見逃すものと、収集ツール自身が与える負荷も挙げてください。
追加取得を提案する場合は、既存ログで代替できないか先に確認してください。
GitHub Copilot CLI に任せれば自動的に正しい原因へ到達する、という話ではありません。今回も途中で WebView2、GPU、Git、maxRequests がそれぞれ怪しく見えました。効いたのは、Copilot CLI に作業を続けさせながら、節目でラバーダックへ「この説明で症状の開始と持続を本当に説明できるか」と反証させたことです。
今回のように調査が長くなったら、Copilot CLI の /share gist でセッション全体を Gist に残しておくと、後から時系列を検索し、スクリプトを追加した理由や判断の変化を追えます。この記事も、その Gist を土台にして何度も仮説を修正した過程まで書き戻しました。
ただし、/share gist はセッション全体を共有します。実行前に、ユーザー名、パス、環境変数、トークン、プロンプト、ファイル内容、顧客・組織名、remote URL、ホスト名、コマンド出力を確認します。URL を知る人が閲覧できる Gist を、機密情報の保管場所とはみなしません。今回は Gist 自体を記事からリンクせず、公開可能な観測結果だけを本文へ持ち込みました。
GitHub Copilot CLI は原因を自動特定するものではなく、調査計画、スクリプト作成、ログ整理を補助する道具として使いました。生成されたコマンドは、変更対象、出力先、必要権限、外部送信の有無を人間が確認してから実行します。プリフライト、反証、収集負荷、機密情報確認まで含めて使うことが前提です。
まとめ
今回確認できたのは、重い GitHub Copilot Agent 作業を複数ウィンドウで並走していた際に、OS 全体の持続的な資源飽和を伴わない UI 遅延を観測したことです。並走が原因だったかは、まだ確定していません。
chat.agent.maxRequests を 1000 から 100 に下げても、UI 遅延は再現しました。100 では Agent が比較的早く続行確認で止まるため、現在は 1000 に戻しています。maxRequests は主因候補から外し、次は保存済みの計測データから、VS Code 内部のどの処理で遅延が生じたかを調べます。
まだ解決編ではありませんが、少なくとも maxRequests=100 は有効な緩和策ではないところまで切り分けられました。