Diagnosing Slow Indexing and High CPU in JetBrains IDEs

Problem: Indexing stalls and CPU stays high after project open

You open your JetBrains IDE and are greeted by a persistent Indexing or Scanning files to index progress bar. Features such as code completion, symbol navigation, and refactoring become slow or unresponsive, and the CPU usage remains elevated long after the project window appears. This state typically lasts several minutes and recurs every time the IDE starts or a new directory is added to the project.

Recognizable condition

The condition is recognizable when the IDE’s status bar shows continuous indexing activity, the editor features you rely on feel sluggish, and the operating system’s task manager or the IDE’s own Activity Monitor reports sustained CPU usage by the idea64 or jetbrains process. If the problem persists beyond the first open of the day or recurs after a fresh start, it signals an underlying configuration or environment factor rather than a one‑time cache miss.

Diagnostic table: common causes and their signs

Cause	Signs you’re likely seeing
Oversized project scope (node_modules, build output, logs, or generated sources inside content roots)	Indexing bar stalls at high percentage; CPU stays high for 10+ minutes; search results omit expected files
Corrupted indexes or caches	Indexing restarts immediately after finishing; repeated "reindex requested" entries in idea.log
Insufficient JVM heap	Chronic garbage‑collection pauses; memory indicator near the configured -Xmx limit; indexing slows as heap fills
Antivirus scanning the project or IDE cache directory	Indexing progress stutters in short bursts; CPU spikes coincide with real‑time scan events
Third‑party plugin with aggressive file listeners	Indexing restarts after brief idle periods; disabling the plugin stops the loop

Ordered checks (perform in this order)

1. Invalidate caches. Choose File | Invalidate Caches and Restart (or the equivalent in your distribution). This clears the internal index and forces a fresh scan. If the index is simply corrupted, a full reindex clears the corruption. After the IDE restarts, note how long the indexing bar runs and whether CPU returns to baseline. If slowness returns immediately, the cause is not cache corruption.

2. Mark build/output directories as Excluded. In the Project tool window, right‑click a directory such as build/, node_modules/, or logs/ and select Mark Directory as | Excluded. This tells the indexer to ignore the directory tree entirely. For monorepos and JavaScript/Java projects, output and dependency directories often exceed 50% of the total file count. Excluding them removes the bulk of the scanning work. Open Ctrl+Shift+F (Search Everywhere) and verify the excluded directory no longer appears in results. Restart the IDE and confirm the indexing bar finishes faster.

3. Check and adjust JVM heap size. Choose Help | Change Memory Settings (or Configure | Edit Custom VM Options on newer versions). If the memory indicator shows the heap near its limit during indexing, increase -Xmx by 512 MiB or 1 GiB increments. When the JVM heap fills, the garbage collector runs more frequently, which manifests as pauses plus high CPU. Giving more headroom lets the indexer allocate buffers without constant GC cycles. The memory indicator in the IDE’s status bar should show usage well below the new limit during a typical indexing run.

4. Isolate non‑bundled plugins. Open Settings | Plugins and disable any plugin not included with the IDE distribution. Alternatively, restart the IDE in a minimal mode by launching with the -Ddisable.plugins flag (or consult your distribution’s safe‑start documentation). Some plugins register file‑system watchers that trigger reindexing whenever a file changes, creating a loop. Removing them isolates whether the indexer or the plugin drives the CPU.

5. Verify antivirus exclusion settings. If your endpoint protection scans ~/.cache/JetBrains/ or the project root in real‑time, add the IDE’s system cache directory and the project’s build output folder to the exclusion list. Real‑time antivirus scans add latency to every file read the indexer performs, turning a smooth reindex into a stuttering loop. Observe indexing timing before and after the exclusion; a measurable improvement typically appears within one reindex cycle.

Fixes tied to findings

• Scope exclusion is the single most common fix. In projects with large node_modules or Gradle/Maven output trees, marking those directories as Excluded reduces initial indexing from 15‑20 minutes to under 2 minutes on typical hardware. This fix applies to IntelliJ IDEA, PyCharm, WebStorm, and other JetBrains distributions that share the same indexing engine.
• Cache invalidation alone may not suffice. If the problem recurs immediately after Invalidate Caches, the root cause is likely directory scope or an external factor, not a corrupted index.
• Heap increase prevents GC‑induced stalls. Raising -Xmx from the default 750 MiB to 1.5 GiB on a 16 GiB RAM workstation typically eliminates the pauses plus high CPU pattern without causing OS swapping.
• Plugin isolation stops reindex loops. After disabling a plugin that registers a WatchService or similar listener, indexing completes in a single pass without restarting.

Escalation criteria

If you have completed all four ordered checks (cache invalidation, directory exclusion, heap adjustment, and plugin isolation) and indexing still stalls with high CPU, gather diagnostic artifacts for JetBrains support:

1. Choose Help | Diagnostic Tools | Create CPU Snapshot during a period of sustained high indexing activity.
2. Choose Help | Show Log and filter for repeated indexing or reindex requested entries. Save the relevant section.
3. File a YouTrack issue and include: IDE version (e.g., IntelliJ IDEA Ultimate 2024.3), operating system, project size metrics (total files, size of excluded directories), and a description of the steps you’ve already taken.

JetBrains engineers use these artifacts to correlate indexing behavior with specific plugin versions or JVM configurations.

Limitations and practical verification

• Menu paths vary. File | Invalidate Caches, Help | Change Memory Settings, and right‑click Mark Directory as may differ between IntelliJ IDEA, PyCharm, WebStorm, and older vs. newer point releases. Always verify the exact path in your own Help menu or via Search Everywhere (double‑press Shift).
• Excluding directories removes code insight. Once a directory is marked Excluded, symbols within it will not appear in Cmd+Click navigation, Shift+Shift search, or refactoring operations. Only exclude directories that are truly build outputs, dependencies, or logs.
• Heap increases consume more RAM. Raising -Xmx beyond the physical RAM available will let the OS swap, which can worsen overall performance. Increase incrementally and monitor the system’s memory pressure.
• Antivirus exclusions reduce protection slightly. Coordinate with your security team before adding IDE cache directories to real‑time scan exclusions.

To verify a fix’s effect, reproduce the problem first: open the project, note the indexing duration and CPU usage from the IDE’s built‑in Activity Monitor or your OS task manager before any change. Apply one fix, then re‑measure indexing time. Repeat for each subsequent fix. This disciplined attribution is the most reliable way to confirm which step actually moved the needle.