VS Code will never be "fast" compared to native editors like Sublime Text or Vim. It's built on Electron, which is basically Chrome disguised as a desktop app. Understanding these limitations helps set realistic expectations and debug performance issues effectively.
The Architecture That Eats RAM
Here's what actually runs when you open VS Code:
- Main process: The core VS Code UI (~200-400MB)
- Renderer process: Your actual editing window (~300-600MB)
- Extension host: All your extensions in one process (~100-500MB)
- Language servers: One per programming language (~50-200MB each)
- Shared process: File watching and workspace indexing (~100-300MB)
I measured VS Code editing a medium React project:
- Base load: around 850MB or so (just VS Code + 5 basic extensions)
- TypeScript language server: +150MB or something like that
- ESLint extension: +70MB
- GitLens: +90MB
- Total: hit around 1.2GB for editing JavaScript files
Compare this to alternatives:
- Sublime Text: around 230MB for the same project
- Vim with plugins: like 70MB
- Notepad++: barely 25MB
The Electron foundation means VS Code will always use more memory than native apps, but Microsoft has spent years optimizing it. Version 1.103 (released August 2025) includes significant memory improvements over earlier versions.
Measuring Performance: Tools That Actually Help
Built-in performance monitoring:
Ctrl+Shift+P → "Developer: Startup Performance" shows you where time goes during boot:
- Extension activation times (anything over 200ms is problematic)
- Language server startup costs
- File indexing overhead
Help → Toggle Developer Tools opens Chrome DevTools for the VS Code interface. Use the Memory tab to see actual RAM usage and identify memory leaks in real-time.
Process Explorer for Windows: Ctrl+Shift+P → "Developer: Open Process Explorer" shows all VS Code processes and their resource usage. This is gold for identifying which component is eating memory.
Real debugging example: Our team's VS Code was eating like 3.2GB on a 8GB laptop. Process Explorer showed:
- Main process: around 400MB (normal)
- Extension host: almost 2GB (fucked)
- TypeScript server: nearly 900MB (also fucked)
The culprits were SonarLint scanning our 50k-file monorepo and TypeScript indexing 15,000 .ts files simultaneously. Both needed configuration changes to run efficiently.
Memory Leak Detection: When VS Code Won't Stop Growing
Signs of memory leaks:
- VS Code memory usage increases over time, even when idle
- Extension host process grows beyond 1GB after a few hours
- TypeScript or other language servers balloon to 500MB+
How to catch leaks:
- Baseline measurement: Note memory usage after a fresh VS Code restart
- Work normally for 2-4 hours without restarting VS Code
- Check Process Explorer: Look for processes that doubled in size
- Identify the leak source: Extension host = extension problem, language server = language tooling issue
Example memory leak hunt: VS Code grew from around 800MB to like 2.4GB over 6 hours. Process Explorer showed the Python extension's language server had ballooned to over a gig. The leak was caused by the Pylsp server analyzing virtual environment files repeatedly. Fixed by excluding venv directories from workspace indexing.
Performance Profiling Extensions
Extensions are the #1 cause of VS Code performance problems. Here's how to identify problematic ones:
Extension Bisect: Ctrl+Shift+P → "Help: Start Extension Bisect"
This systematically disables extensions until it finds the performance killer. Takes 3-4 VS Code restarts but saves hours of manual testing.
Extension performance monitoring:
Ctrl+Shift+P → "Developer: Show Running Extensions"
This shows CPU usage and activation times for all extensions. Extensions using more than 10% CPU continuously are problematic.
Most common performance destroyers:
- Bracket Pair Colorizer (now built-in to VS Code 1.60+): Uninstall the extension version
- Live Server: Struggles with projects containing 50+ HTML files
- Python extension: Memory leaks in conda environments
- GitLens: Performance degrades exponentially with repository size
- Prettier + ESLint + TypeScript: Running simultaneously causes keystroke delays
Workspace Configuration: Making Large Projects Bearable
Large codebases expose VS Code's performance limitations. Our massive 2GB+ monorepo: git status takes like 45 seconds in VS Code but under a second in terminal.
File watching limits: VS Code can monitor about 8,000 files before performance degrades. Configure exclusions in .vscode/settings.json:
{
"files.exclude": {
"**/.git": true,
"**/.DS_Store": true,
"**/node_modules": true,
"**/dist": true,
"**/build": true,
"**/*.pyc": true
},
"files.watcherExclude": {
"**/.git/objects/**": true,
"**/.git/subtree-cache/**": true,
"**/node_modules/**": true,
"**/tmp/**": true,
"**/dist/**": true
}
}
TypeScript project optimization: Large TypeScript projects kill VS Code performance. Add to tsconfig.json:
{
"compilerOptions": {
"skipLibCheck": true,
"incremental": true
},
"exclude": [
"node_modules",
"dist",
"build"
]
}
skipLibCheck prevents TypeScript from analyzing node_modules type definitions. incremental caches compilation results between builds.
When to Give Up and Use Alternatives
VS Code breaks down with:
- Repositories over 1GB (Git operations become unusable)
- Files over 50MB (syntax highlighting locks up the UI)
- Projects with 100+ extensions (startup takes 10+ seconds)
- TypeScript projects with 10,000+ files (IntelliSense becomes a joke)
Better alternatives for these scenarios:
- Large files: Use
vimorlessin terminal - Massive repositories: JetBrains IDEs handle large codebases better
- Simple editing: Sublime Text is still 10x faster for basic tasks
- Performance-critical work: Native editors like Nova or BBEdit
The harsh reality: VS Code's Electron architecture has fundamental performance limitations. When performance becomes critical, specialized tools designed for your specific use case will always be faster than a general-purpose, Electron-based editor trying to do everything.