Establish a Baseline Before Blaming Anything
The precondition for any diagnosis is turning a vague feeling into data. Run `Developer: Show Running Extensions` to list each extension activation time, `Developer: Toggle Performance` for typing latency and render times, and note which helper process owns the CPU.
Separating renderer from extension host matters. High typing latency with idle extension hosts points at the renderer or a language server such as tsserver; sustained high CPU in `Code Helper (Plugin)` almost always names the culprit. Remember the role split visible in Task Manager: `Code Helper (Renderer)`, `Code Helper (Plugin)`, and `Code Helper (Watcher)` — the last one owns file watching exclusively.
A mandatory step is capturing a process and memory snapshot with `code --status`, then reproducing in an empty window: `code --disable-extensions .`. If the project is still slow with every extension disabled, the cause lies in editor settings, file count or the workspace itself.
# 空窗口打开，禁用全部扩展——最直接的归因手段
code --disable-extensions .
# 只跑单个扩展，用于二分定位
code --disable-extensions --locate-extension ms-python.python
# 查看当前会话进程与内存快照
code --status
# 界面内操作
# 命令面板 -> Developer: Show Running Extensions
# 命令面板 -> Developer: Toggle Performance
# 命令面板 -> Developer: Open Extension Host LogsBisecting Extensions
With few extensions (under 20) disabling them one by one is fastest. With many, bisect: move all extensions to a temp directory, restore half, and repeat until one extension remains. Bisection turns N trials into log2(N) — 40 extensions need only 6 rounds.
An even better daily routine uses three commands. Sort `Developer: Show Running Extensions` by activation time and suspect the slowest; run `Developer: Restart Extension Host` and see whether the lag disappears; then check `Developer: Open Extension Host Logs` for repeated errors or loops.
Once identified there are three responses: upgrade (many perf issues are fixed upstream), pin the version via a lockfile so the whole team matches, or recommend disabling through `"unwantedExtensions"` in `extensions.json`. Note that a recommendation is not enforcement — users can still install it.
// .vscode/extensions.json —— 团队统一扩展集合与禁用建议
{
"recommendations": ["dbaeumer.vscode-eslint", "esbenp.prettier-vscode"],
"unwantedExtensions": [
{
"identifier": {
"id": "some.heavy-extension"
},
"recommendation": "该扩展在大型仓库中显著拖慢启动，请在团队内统一禁用"
}
]
}
// 二分定位脚本骨架（Bash）
// 1) 备份当前扩展目录
// 2) 循环：恢复一半扩展 -> code --disable-extensions . 复现 -> 记录卡顿程度files.exclude and search.exclude: Scoping Indexing and Search
These two settings are constantly confused. `files.exclude` hides files from the explorer and tree; `search.exclude` skips files during search. Glob patterns (not plain paths) let you filter by filename or extension precisely.
What actually costs performance is generated directories that are only implicitly excluded: `.git`, `node_modules`, `dist`, `build`, `.next`, `target`, `vendor`. VS Code excludes some by default, but once you `Add Folder to Workspace` or adopt a monorepo layout, the defaults are rarely enough.
A sound principle: exclude generated directories from the tree to reduce watching and rendering pressure, and exclude huge binary directories from search to avoid reading megabytes of content per query. Enable `search.useIgnoreFiles: true` and `search.useGlobalIgnoreFiles: true` so `.gitignore` and `.ignore` apply — this single pair fixes most search stalls.
// settings.json
{
"files.exclude": {
"**/.git": true,
"**/node_modules": true,
"**/dist": true,
"**/build": true,
"**/.next": true,
"**/target": true,
"**/.venv": true,
"**/*.log": true
},
"search.exclude": {
"**/node_modules": true,
"**/dist": true,
"**/build": true,
"**/target": true,
"**/*.min.js": true,
"**/*.map": true,
"**/pnpm-lock.yaml": true
},
"search.useIgnoreFiles": true,
"search.useGlobalIgnoreFiles": true,
"search.smartCase": true
}Tuning Indexing and File Watching on Large Repositories
In repositories with hundreds of thousands of files, the file watcher saturates inodes and CPU. The three most effective Linux-side moves: point `files.watcherExclude` at generated directories, prefer native recursive watching (`files.watcherUsePolling: false` — never enable polling by default), and on container or network filesystems use a gVisor-style FS to reduce inode events.
TypeScript projects need dedicated tuning: raise `typescript.tsserver.maxTsServerMemory` (e.g. 4096), set `typescript.disableAutomaticTypeAcquisition: true` to stop auto-fetching `@types` packages that trigger a second indexing pass, and consider `typescript.tsserver.useSyntaxServer` for the lighter syntax-only server.
Two underused editor switches matter too: `editor.codeLens: false` and `editor.minimap.enabled: false` measurably reduce rendering cost on large files. Keep `files.hotExit` at its default so closing a window does not serialize unsaved state and fake a stall. After changing settings run `Developer: Reload Window` to rebuild the index, then compare `Developer: Toggle Performance` readings.
// 大仓库 settings.json
{
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/node_modules/**": true,
"**/dist/**": true,
"**/build/**": true,
"**/.next/**": true
},
"files.watcherUsePolling": false,
"typescript.tsserver.maxTsServerMemory": 4096,
"typescript.disableAutomaticTypeAcquisition": true,
"editor.codeLens": false,
"editor.minimap.enabled": false,
"files.hotExit": "onExitOnly",
"search.followSymlinks": false
}