Thanks for taking the time to go into so much detail on this issue. With the information you've provided, my best empirical analysis is that the issue is caused by overall resource load on your machine interfering with the responsiveness of the IDE.

NCrunch makes use of a O/S level feature called processor affinity, which allows its sub-processes to run on separate CPU cores to VS. In theory, this allows us to max out a part of your CPU while reserving another part for the VS experience.

In practice, it's not perfect. Hyper-threading can cause some level of interference across the affinity wall. There is also the risk of some sub-processes not sticking with the affinity pattern. One of the problems we've had the most trouble with is the Roslyn compiler, as it actually gets hosted in the O/S as a singleton EXE that has instructions passed to it through IPC. This singleton is shared between both VS and NCrunch, and there is always the chance that it can spawn other child processes depending on the needs of the development platform. There is also the risk of other sub-processes being launched from the build system with complex interactions that are outside of our control.

Finally, to my knowledge, there is no way to set such a barrier in place for I/O operations. This means that if Visual Studio has some kind of I/O action that might lock its primary thread (even for the slightest amount of time), and your SSD/HDD is oversubscribed with a range of background build tasks, this can then impact the IDE performance. The building of projects on disk is a very I/O intensive process.

There's several ways you can mitigate this:
- Try running with less background processes (i.e. set the 'Max number of processing threads' to a lower value)
- Consider moving your workspace base path to a RAM disk if you have the memory resources
- Make sure your NCrunch CPU core assignment settings don't split a physical CPU across the barrier (i.e. split your cores in even numbers if you have hyper-threading)
- Consider using the sliding build delay setting
- Avoid working with a large number of files open in VS at one time
- Distributed processing

Finally, I've dreaded the day where I would need to say this, but 8 logical CPU cores (4 physical?) running under VS2019 on a solution with 70 projects is probably going to be a stretch for hardware. Successive versions of Visual Studio have been eating more and more CPU, with many of the optimisation strategies employed by the teams at MS being focused on making more and more use of background cores. This means that NCrunch is being pushed into a progressively smaller corner to work from. Under VS2017 we observed a large solution needed at least 3 logical cores to avoid noticed loss in performance. Under VS2019 we're up to 4. Large chunks of code and complex toolsets may push that number even higher. If poor performance is impacting your work efficiency, it may be time to consider upgrading your hardware or pushing some work off to a remote machine using distributed processing.

Can definitely recommend the distributed processing. Our lower powered devices have local processing disabled and rely solely on grid nodes.

Remco: Is it possible to disable the affinity options (is it as simple as putting all of my cores in both options)? As you've configured the processes properly with priority etc, I'd rather rely on the OS to do the scheduling

today I installed version 3.31.0.3 and the lag returned with a vengeance. Visual Studio 2019 just hangs until it crashes. I read the other posts. Im going to fiddle with the number of cores.
Nothing helped. I had to disable ncrunch. Perhaps any other advice?