How to Optimize VS Code for Large Projects: A Deep Dive into Performance

The Struggle with Scale

We’ve all been there: you open a project with 50,000+ files, and suddenly VS Code feels like it’s running through molasses. IntelliSense takes five seconds to trigger, the file explorer stutters, and your RAM usage spikes to 4GB just for the editor. When you need to optimize VS Code for large projects, you aren’t just looking for ‘tips’—you’re looking to stop the editor from choking on its own indexing process.

In my experience working on enterprise-level monorepos, the bottleneck is rarely the hardware; it’s usually how VS Code interacts with the file system and the background processes spawned by extensions. If you’re feeling the lag, it’s time to move beyond default settings.

The Challenge: Why VS Code Slows Down

VS Code is built on Electron, meaning it’s essentially a Chrome browser running your code. While powerful, it has inherent memory overhead. In large projects, the primary performance killers are:

File Watching: The editor tries to track every single change in your workspace to update the explorer and search results.
Indexing: Language servers (like TSServer for JavaScript/TypeScript) scan every file to provide autocomplete.
Extension Overhead: Every extension you install adds another layer of processing to every keystroke.
Node Modules: Including node_modules in the search index is the fastest way to kill your CPU.

VS Code Process Explorer showing high CPU and memory usage for the Extension Host

Solution Overview: The Three-Pronged Approach

To truly optimize the environment, I use a strategy I call Restrict, Audit, and Isolate. Instead of hoping the editor gets faster, we explicitly tell it what to ignore and how to prioritize resources. This involves modifying the settings.json, auditing the Extension Host, and utilizing specialized workspace configurations.

Techniques for Maximum Performance

1. Restricting the File Watcher and Search

The most immediate gain comes from telling VS Code to stop looking at things it doesn’t need to. By default, VS Code ignores some folders, but in large projects, you need to be aggressive. I’ve found that excluding build artifacts and huge dependency folders significantly reduces CPU spikes.


{
  "files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/.next/**": true
  },
  "search.exclude": {
    "**/node_modules": true,
    "**/dist": true,
    "**/build": true,
    "**/.git": true
  }
}

2. Taming the Language Server

If you’re working in TypeScript, the TSServer can be a memory hog. I recommend limiting the scope of the project using a tsconfig.json that specifically excludes non-essential directories. Additionally, you can disable certain ‘expensive’ features that you might not need in a massive codebase.

For those managing complex environments, I highly recommend learning how to use dev containers in VS Code. By isolating the project in a container, you can allocate specific CPU and RAM limits to the environment, preventing the editor from freezing your entire OS.

3. The Extension Audit

Not all extensions are created equal. Some run lightweight scripts, while others spawn heavy background processes. To find the culprit, use the built-in Process Explorer (Help > Open Process Explorer). I’ve discovered extensions that were consuming 500MB of RAM just to provide a niche syntax highlight.

If your keyboard shortcuts feel sluggish, check out my VS Code keyboard shortcuts cheat sheet to ensure you’re using the most efficient navigation patterns, reducing the need to constantly trigger the heavy file explorer UI.

Implementation: Putting it All Together

To implement these changes across a team, don’t rely on individual settings. Create a .vscode/settings.json file within your project root. This ensures every developer on the project inherits the same optimizations.

Here is my ‘Large Project Template’ for .vscode/settings.json:


{
  "editor.minimap.enabled": false,
  "editor.folding": false,
  "git.autorefresh": false,
  "workbench.startupEditor": "none",
  "files.exclude": {
    "**/.git": true,
    "**/.svn": true,
    "**/.hg": true,
    "**/CVS": true,
    "**/node_modules": true
  }
}

Disabling the minimap and code folding in massive files (over 5,000 lines) provides a noticeable boost in scrolling smoothness, as shown in the Process Explorer benchmarks I’ve tracked in my own setup.

Case Study: 100k File Monorepo

I recently optimized a project for a client with over 100,000 files. Initially, the project took 45 seconds to ‘warm up’ before IntelliSense worked. By implementing files.watcherExclude and moving the build process to a Dev Container, we reduced the warm-up time to 12 seconds and cut the average RAM usage from 3.2GB to 1.4GB. The key was shifting the heavy lifting away from the UI thread and into the containerized backend.

Pitfalls to Avoid

Over-excluding: Be careful not to exclude folders you actually need to search. If you exclude src/legacy, you won’t find the code you’re trying to refactor.
Extension Overload: Avoid installing ‘Pack’ extensions. Only install the specific tools you need.
Ignoring the Cache: Occasionally, the VS Code cache gets corrupted in large projects. If things feel slow despite optimizations, try clearing the Global Storage folder.

Ready to take your productivity further? I’ve written more about automation tools that can handle the tasks VS Code struggles with, such as large-scale refactoring across thousands of files.