JetBrains Rider and .NET SDK: Solution-wide Analysis Resource Reclamation

Short answer

No — toggling Solution-wide Analysis (SwA) off in Rider does not trigger an immediate garbage collection or memory release in the ReSharper host process (Rider.Backend). The memory allocated for the global analysis cache is retained, largely by design, and the only guaranteed full reclamation is restarting the backend process (i.e., restarting Rider). The .NET SDK version influences the cache footprint only indirectly — through solution size, target framework reference assemblies, and generated code volume — not through any special transition behavior when SwA is disabled.

What is confirmed vs. likely

Confirmed behavior: SwA builds persistent caches of symbols, references, and inspection results across the whole solution. These caches are the dominant source of the backend process's managed and native memory use. Retention after analysis completes — or after the feature is switched off — is intentional caching to keep navigation, find-usages, and refactorings fast. A visible memory drop after disabling SwA is not expected behavior.

Likely explanation for what you observe: when you disable SwA, the engine stops scheduling whole-solution passes, so CPU overhead drops quickly. But the already-materialized cache structures remain referenced and eligible for reuse, so the GC has no reason to collect them, and even collected managed memory is often not returned to the OS promptly. In virtualized environments with memory ballooning, this looks like a leak; it is usually just a retained working set.

What actually reclaims memory

1. Scope the analysis instead of expecting reclamation. In Settings | Editor | Inspection Settings, disable "Enable solution-wide analysis" or switch to errors-only mode. Do this before the first full pass on a large solution — it reduces peak memory, not just ongoing CPU.
2. Exclude noise from indexing. Remove bin, obj, node_modules, and large generated folders from the project view. This shrinks the cache that would otherwise be retained.
3. Restart between large solutions. A known historical pattern is cache accumulation when opening a second large solution in the same session. Closing Rider entirely is the reliable reclamation path.
4. Power Save Mode stops background analysis but does not release existing caches either — treat it as a CPU lever, not a memory lever.

Verifying on your installation

Toggle names and memory behavior vary by Rider version, so verify rather than trust older docs:

• Watch the backend process memory via the status-bar memory indicator or your OS task manager before and after a full SwA pass, then after disabling it. Expect CPU to fall and memory to stay roughly flat.
• Use Help | Diagnostic Tools to capture a backend memory snapshot.
• The distinguishing test for a real defect: if memory grows while the IDE is idle with no edits and no analysis running, capture a snapshot and file a YouTrack issue. Stable high retention after analysis is by design; unbounded idle growth is not.

On the .NET SDK question

Newer SDKs change the footprint mainly by changing what gets analyzed: more reference assemblies, source generators emitting additional files, and larger default scaffolding all grow the cache. There is no documented SDK-version-specific behavior for cache release on SwA toggle — treat any such claim as unverified and measure on your own solution. If you share your Rider version and approximate solution size (project count, generated-code volume), the recommendation between "errors-only mode" and "exclude folders + restart cadence" can be narrowed further.