IntelliJ IDEA Performance Issue - Multiple Project Windows Hang During Project Analysis/Indexing

Thanks for the report, and for laying out your setup and questions.

What you are seeing is a known limitation in how IntelliJ IDEA handles several open projects at once, not a problem with your machine or your memory settings.

All of your open project windows run inside a single IDE process (one JVM), and that process uses one application-wide read/write lock. While a project is scanning or indexing ("Analyzing project to enable smart features"), the indexing work holds a read lock, and a held read lock prevents the IDE from acquiring the write locks the UI needs. Since every window shares that one lock, indexing in one project blocks the UI of all the other windows until it finishes.

That also covers the rest of your questions:

- Allocating 30 GB was a reasonable thing to try, but this particular freeze is not a memory issue, so extra heap will not change it. Nothing is running out of memory here. The pause comes from lock contention while indexing runs. One small thing to keep in mind: very large heaps can lead to longer garbage collection pauses, so a more moderate size is usually fine for this workload.
- It is closer to CPU and disk bound. Scanning and indexing are limited mostly by CPU and disk speed, and the freeze lasts as long as that work holds the lock.
- There is not a setting that makes each window fully independent today. Additional windows always attach to the same process, so running the two projects as genuinely separate IDE processes is not something the IDE offers out of the box yet. The read-lock work mentioned below is the real fix for this.

The platform team is actively working on removing these read locks from scanning and indexing so this cross-project blocking goes away. You can follow the progress and subscribe for updates here: https://youtrack.jetbrains.com/issue/IJPL-242703 (see [Watching YouTrack issues](https://intellij-support.jetbrains.com/hc/en-us/articles/207241135) for how to vote and get notified).

In the meantime, the practical goal is to make indexing finish faster so it holds the lock for less time:

1) Exclude large or generated folders that do not need to be indexed (build output, caches, node_modules, large data directories). Right-click the folder in the Project view and choose Mark Directory as, then Excluded.
2) Keep your projects on a fast local disk. Projects on network drives, or reached through WSL paths, take much longer to scan.
3) Stay on the latest 2026.1.x build. Changes that reduce read-lock usage during indexing are landing incrementally.

If you would like us to look at your specific case, a CPU snapshot captured while the windows are frozen would tell us exactly what the indexing is spending time on. The snapshot menu runs on a separate thread, so it works even when the UI looks stuck. The steps are in [Reporting performance problems](https://intellij-support.jetbrains.com/hc/en-us/articles/207241235). It also helps to attach the logs from Help, then Collect Logs and Diagnostic Data.

Let us know if the workarounds help, or send a snapshot and we will dig into it.

Thanks for following up.

**What the "lock" actually is**

You are right that it is not a lock on files. It is an in-memory read/write lock inside the IDE process: reading the project model uses a read action, changing it (including most UI updates) uses a write action, and a write action cannot start while a read action is in progress. Scanning and indexing run as long read actions, so while they hold that lock the UI write actions of every window in the same process have to wait, and that wait is the freeze you see.

**On excluding folders**

Agreed, it is not a complete fix when you need the whole codebase indexed. Excluding folders only makes indexing finish sooner, so the lock is held for less time. It does not remove the contention, and the real fix is on our side: stop holding the read lock during scanning and indexing. That work is tracked in [IJPL-242703](https://youtrack.jetbrains.com/issue/IJPL-242703).

That said, I would still go through the project for large folders or file types that you do not actually need indexed or searchable (build output, caches, generated sources, large data directories) and exclude those. Excluding a folder does not lock you out of it for search either: you can still search inside an excluded folder on demand by opening Find in Files, setting the scope to Directory, and pointing it at that folder. Excluded folders are only left out of the default "In Project" scope, so the only cost is that you have to target them explicitly when you do need to search them.

**On 2026.1**

I want to be accurate here rather than point you at a single build that fixes everything. Removing read actions from indexing is a larger effort that lands incrementally, not one switch that flips on in 2026.1. [IJPL-242703](https://youtrack.jetbrains.com/issue/IJPL-242703) is the umbrella for it, and several related indexing and scanning performance fixes are currently going out in 2026.2 EAP builds. The most reliable way to track the part that affects your case is to watch [IJPL-242703](https://youtrack.jetbrains.com/issue/IJPL-242703) directly. As individual pieces ship, they show up there.

**On the freezing you saw in 2025.3.6**

This one is worth separating out. In your message, the tracker link text says IJPL-242703, but the link itself points to IJPL-237769. Those are two different issues, and the distinction matters here:

- [IJPL-242703](https://youtrack.jetbrains.com/issue/IJPL-242703) is the indexing read-lock work. That is the right one for the "all windows freeze while one project indexes" behavior we have been discussing.
- [IJPL-237769](https://youtrack.jetbrains.com/issue/IJPL-237769) is a separate, more recent regression: the UI freezing when you open a large directory in the navigation bar and type to filter it, which matches the "Search in Path" / file path search freeze you reported earlier. That is a problem in the navigation bar's filtering, not the indexing lock.

So the freezing that started for you in 2025.3.6 is the second one, tracked in [IJPL-237769](https://youtrack.jetbrains.com/issue/IJPL-237769). If that is what is making you hold off on upgrading, following IJPL-237769 will tell you when that specific regression is fixed, separately from the indexing work.