UI latency during concurrent builds with solution-wide analysis enabled
0 reputation · 10 Sept 2020, 10:09 UTC
0 reputation · 10 Sept 2020, 10:09 UTC
Rider runs solution-wide analysis in a separate backend process while the UI remains responsive. On large solutions, concurrent operations such as building, NuGet restore, or opening many files can compete with that backend process for CPU and memory, producing latency that appears only under concurrent requests. The analysis scope and severity rules are configurable, and the feature can be disabled or limited to opened files, but it is unclear whether Rider automatically pauses or deprioritizes solution-wide analysis during a build.
Assume a recent Rider major version where solution-wide analysis defaults are version-sensitive. The goal is to confirm whether this contention is expected behavior or a configurable threshold, and whether disabling analysis for unopened files changes the outcome.
Does Rider throttle solution-wide analysis during concurrent build or restore operations? Is the backend resource contention documented as expected for large solutions? Which setting controls analysis priority relative to solution operations?
Rider does not automatically throttle or deprioritize solution-wide analysis during concurrent build or NuGet restore operations. The analysis backend continues to operate at standard OS priority alongside MSBuild, which can lead to CPU and memory saturation on large solutions, manifesting as UI latency.
Resource contention between the analysis process and build tools is expected behavior for large-scale projects. Because the Rider backend and the build engine compete for the same hardware resources, the UI may become unresponsive if the system cannot handle the combined load of indexing, analyzing, and compiling.
There is no specific setting to adjust the process priority of the analysis backend relative to other solution operations. Control is managed exclusively through the scope of the analysis and the severity of the inspections.
To mitigate contention during heavy build cycles, adjust the analysis scope to reduce the backend load:
Switching to "Opened files only" significantly reduces the number of files the backend must track and analyze, freeing up CPU cycles for the build process and improving UI responsiveness.
To confirm if this is the cause of your latency, you can perform the following test:
Note: To provide a more specific recommendation, please clarify if you are using a remote development environment (via JetBrains Gateway) or a local installation, as memory pressure behaves differently in distributed setups.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.