Optimize VS Code Performance: File Watchers & Exclusions

When you’re working in a massive monorepo, VS Code often starts lagging. You’ll notice the search feature hangs, or the editor stops picking up file changes in real-time. It’s frustrating, and I’ve spent more than a few afternoons debugging it.

The culprit is almost always the file watcher. VS Code uses a service to watch for filesystem changes, but it has a hard limit on how many files it can monitor. Once you cross that threshold, your IDE essentially goes blind to your local changes.

Understanding VS Code File Watcher Limits

By default, VS Code tracks changes to your files to keep the IntelliSense cache and explorer view accurate. If you’re on Linux, you’re likely hitting the system’s fs.inotify.max_user_watches limit. Before you go overboard, it’s worth checking if you actually need to monitor every single file in your project.

If you're hitting the "too many open files" wall, you should first understand the difference between system-level limits and IDE-level settings. If you’re running into OS-level bottlenecks, you might need to increase open file limits to give the editor more breathing room.

How to Optimize VS Code Files Exclusions

The most effective way to optimize VS Code is to tell it to ignore the directories you don't actually need to search or index. I’ve seen projects where node_modules, dist, or build folders consume 80% of the watcher’s capacity.

Open your settings.json and add these paths to files.watcherExclude:

JSON
"files.watcherExclude": {
    "**/.git/objects/**": true,
    "**/.git/subtree-cache/**": true,
    "**/node_modules/*/**": true,
    "**/dist/**": true,
    "**/build/**": true,
    "**/target/**": true
}

This immediately reduces the load on the watcher. I usually start by excluding node_modules and any generated build artifacts. If you’re working in a complex environment, you might also want to optimize TypeScript monorepos for speed to further reduce the overhead of language servers.

Comparing Tuning Approaches

Beyond File Watchers: A Holistic Look

If you've cleaned up your watcher and you're still seeing high memory usage, the problem might be your extensions. I’ve written before about how to optimize VS Code memory usage by auditing what’s running in the background. It’s easy to install a dozen tools and forget they’re eating your RAM.

I’ve also found that keeping your workspace clean is a constant battle. Sometimes, the best way to handle performance is to move heavy tasks off your local machine entirely. If you're struggling with local storage or file management, custom email & file storage systems can help offload non-essential data from your primary workstation.

Troubleshooting Steps

1. Check your logs: Open the "Output" panel and select "Log (Window)" to see if VS Code is reporting watcher errors.
2. Use the Command Palette: Run Developer: Reload Window after changing settings to ensure the new watcher rules take effect.
3. Limit search: Use search.exclude in your settings to keep the global search from crawling through your node_modules or vendor folders.

I’m still experimenting with how different language servers interact with these exclusions. Sometimes, excluding a folder breaks "Go to Definition" functionality. If you find yourself needing to jump into node_modules occasionally, don't exclude them globally—use workspace-specific settings instead. It’s a bit more work, but it keeps your main project fast while keeping your dependencies accessible when you really need them.

FAQ

Why does VS Code say "File watcher limit reached"? It means your OS has a limit on how many file handles can be watched at once. You’ve exceeded this limit by having too many files in your workspace, or by including directories that change frequently (like build logs).

Does excluding files make search slower? No, it makes it faster. By adding directories to search.exclude and files.watcherExclude, you reduce the amount of data VS Code has to scan, which significantly improves search performance.

Will these settings affect my project build? No. These settings only change how the VS Code editor monitors your project for UI updates and IntelliSense. Your actual build commands in the terminal will still see and use those files.