VS Code is not the problem. Eighteen extensions are the problem.
On a fresh install, VS Code idles around 300–400 MB. Mine was using 780 MB and taking over nine seconds to become usable. After removing twelve extensions, startup dropped to four seconds and memory fell by about 180 MB — enough to keep a browser open while editing.
Here is the measurement method and the exact list I kept.
The result
18 extensions → 6. Startup 9.2 s → 4.0 s. Idle memory 780 MB → 600 MB. No loss of editing capability for Python or web work.
Measure first
Open the command palette (Ctrl+Shift+P) and run:
Developer: Startup Performance
You will get a breakdown of activation time per extension. Ignore the total; look for the top three. That is where the seconds are.
Then check memory: Ctrl+Shift+P → “Developer: Open Process Explorer”. You will see the main process, renderer, extension host and each language server. The extension host is usually the biggest offender.
Do not trust “lightweight” labels
An extension's install size says nothing about its runtime cost. An icon theme can be 50 MB on disk and nearly free at runtime; an AI assistant can be 5 MB and spawn a 300 MB language server. Measure, do not guess.
What I removed, and why
| Extension | Why it went | Cost |
|---|---|---|
| Second AI assistant | Duplicated Pylance; ran a background model | ~250 MB, 2–3 s |
| Docker | Not used daily; heavy activation | ~1 s |
| Remote – WSL | Not used on this machine | ~0.5 s |
| Live Share | Rarely used | ~0.3 s |
| Git Graph | Built-in Git view is enough | ~100 MB |
| Project Manager | Workspaces do the same thing | ~0.2 s |
| TODO Tree | Ran a workspace scan on every open | ~0.4 s |
| Bracket Pair Colorizer | Native in VS Code now | ~0.2 s |
| Prettier | Ruff handles Python; built-in formatting for the rest | ~0.3 s |
| Path Intellisense | Built-in suggestions are fine | ~0.1 s |
| npm Intellisense | Same | ~0.1 s |
| Icon theme (second) | One theme is enough | ~0.1 s |
None of these are bad extensions. They are just not worth their cost on this machine.
What I kept
| Extension | Purpose | Why it earns its place |
|---|---|---|
| Python | Interpreter, debugging, testing | Required for Python work |
| Pylance | Types and completions | Fast, bundled with Python |
| Ruff | Lint + format | Replaces three tools |
| Error Lens | Inline errors | Zero noticeable cost |
| GitLens | Blame and history | Disable its “current line” features if slow |
| One theme | Readability | Pick one and stop |
That is enough for Python, JavaScript, Markdown and shell scripting.
The settings that matter
settings.json (Ctrl+Shift+P → “Preferences: Open User Settings (JSON)”):
{
"editor.minimap.enabled": false,
"editor.renderWhitespace": "boundary",
"workbench.startupEditor": "none",
"extensions.autoUpdate": "onlyEnabledExtensions",
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.venv/**": true,
"**/node_modules/**": true,
"**/__pycache__/**": true
},
"search.followSymlinks": false,
"telemetry.telemetryLevel": "off"
}
The two big wins are the watcher excludes and disabling the minimap on a small screen. File watching on a large node_modules or .venv folder can consume real CPU.
For Python specifically:
{
"python.analysis.diagnosticMode": "openFilesOnly",
"python.analysis.indexing": false
}
Pylance indexes your whole environment by default. On a 256 GB SSD with a large venv, that is slow. Indexing only open files is a good trade for small projects.
Use profiles instead of installing everything
VS Code profiles let you keep separate extension sets:
- Python — Python, Pylance, Ruff, Error Lens
- Web — ESLint, Prettier, a browser preview
- Writing — Markdown lint, spell check
Switch with Ctrl+Shift+P → “Profiles: Switch Profile”. Each profile only loads its own extensions, so the cost is paid only when relevant.
Workspace-level disabling is even finer: right-click an extension → “Disable (Workspace)”.
What about AI extensions?
An AI coding assistant is the most expensive thing you can add to VS Code on 8 GB. A local model via Continue adds the model's memory plus prompt latency; a cloud assistant adds a background process and network calls.
My compromise: keep the assistant installed but disabled, and enable it only when I need it. The local coding assistant field report has the measured latency if you are considering a local model.
When VS Code is still too heavy
If 600 MB is still too much, the alternatives are real:
- Sublime Text — 100–200 MB, very fast, paid licence.
- Neovim — 50–100 MB with a small config, free, steeper learning curve.
- Notepad++ — tiny, Windows-only, fine for scripts.
For most people, a trimmed VS Code is the right balance. The point is not to win a memory contest; it is to leave enough RAM for the compiler, the browser and, occasionally, a language model.
The one-minute audit
- Run “Developer: Startup Performance”.
- Disable the top three slowest extensions.
- Restart, measure again.
- Repeat until startup is under five seconds.
- Uninstall anything you have not used in a month.
FAQ
Does clearing the extension cache help?
Rarely. The cost is loading code, not reading it from disk. Fix the extension list first.
Should I disable telemetry?
It is good practice, and the CPU cost is negligible. Do it for privacy, not speed.
Will a faster SSD fix slow startup?
A little. Startup is dominated by extension activation and language server initialization, which are CPU-bound.
Is VS Code Insiders faster?
No, and it adds instability. Use the stable build.