Resolving High CPU and Indexing Loops in PhpStorm

The Indexing Bottleneck

PhpStorm's ability to provide precise autocomplete and navigation depends on its index—a comprehensive map of your project's symbols and relationships. However, when the IDE attempts to index non-code directories like /storage, /var/log, or massive /vendor folders containing generated artifacts, CPU usage spikes, the UI may freeze, and the "Indexing..." progress bar may never disappear.

The goal is to restrict the IDE's scope to only the files necessary for static analysis, reducing memory pressure and disk I/O.

Diagnostic Matrix: Identifying the Root Cause

Symptom	Likely Cause	Primary Diagnostic Tool
Constant CPU spikes during idle time	Indexing large data/log folders	Activity Monitor
Indexing loop (starts over repeatedly)	Corrupted index cache	Status Bar Progress
Frequent "Out of Memory" or UI lag	Insufficient JVM Heap size	Memory Indicator
Slow search/navigation in specific files	Over-exclusion of source folders	Project Structure View

Step-by-Step Resolution Path

1. Isolate Resource-Heavy Processes

Before changing configurations, identify if the CPU spike is caused by the indexer or a specific plugin. Run this on your local machine:

• Navigate to Help > Diagnostic Tools > Activity Monitor.
• Look for Indexing or File System Watcher in the list.
• If a specific plugin is consuming high CPU, disable it via Settings > Plugins.

2. Exclude Non-Code Directories

PhpStorm indexes every folder in the project root by default. You must manually exclude directories that contain generated data, caches, or logs.

1. Go to Settings > Directories (Ctrl+Alt+S).
2. In the project tree, locate folders such as node_modules, var/cache, storage/logs, or tmp.
3. Select the folder and click the Excluded button (marked in red).
4. Click Apply. The IDE will immediately remove these files from the index.

Risk: Excluding a folder prevents Ctrl+Shift+F (Find in Files) from searching within that directory. If you need to search logs occasionally, use an external editor or temporarily unmark the folder.

3. Adjust JVM Heap Memory

If the IDE freezes during indexing, the Java Virtual Machine (JVM) may be hitting its memory ceiling, triggering aggressive Garbage Collection (GC) cycles.

1. Navigate to Help > Change Memory Settings.
2. Increase the Maximum Heap Size. For projects with large vendor directories, 2048 MiB or 4096 MiB is typically sufficient.
3. Restart the IDE to apply changes.

Verification: Enable the memory indicator by right-clicking the bottom status bar and selecting Memory Indicator. Monitor the used vs. allocated memory during the next index cycle.

4. Clear Corrupted Caches

If the indexing process restarts infinitely or fails to recognize newly added files, the local cache may be corrupted.

1. Go to File > Invalidate Caches....
2. Check Clear file system cache and Local History.
3. Click Invalidate and Restart.

Warning: This operation deletes all existing indices. Depending on project size, the subsequent full re-index can take several minutes and will consume significant CPU.

Comparison: Excluded vs. Library Root

When dealing with /vendor folders, you have two choices. Choosing the wrong one can either break autocomplete or slow down the IDE.

Strategy	Behavior	Best Use Case
Excluded	Completely ignored by the IDE. No indexing, no search.	Log files, temp uploads, cache folders.
Library Root	Indexed for symbols/navigation but treated as read-only.	Composer/npm dependencies (standard vendor).

Escalation Criteria

If CPU usage remains above 80% after excluding directories and increasing heap size, check the following:

• Disk I/O: If the project is on a network drive (NFS/SMB) or a slow HDD, the File System Watcher may struggle. Move the project to an SSD.
• Symlinks: Check for recursive symlinks in your project structure that might cause the indexer to loop infinitely.
• Plugin Conflict: Disable all non-bundled plugins and restart to see if a third-party extension is triggering the indexer.