UI hangs for ~3 sec each time when running automatically

Hi, I have an issue whereby as I'm changing the code for my solution (with run impacted tests automatically ticked), the Visual Studio UI will hang for around 3 seconds each time, and be unresponsive to any input.
Is there something I can do to diagnose the issue?

Thanks
Kieren

Hi Kieren,

Thanks for sharing this issue.

We're extremely careful to stay off the UI thread under NCrunch, so I'm not sure if this is being caused by us. The quickest way to know is to launch a second instance of VS, and attach a debugger to the first instance. When the first instance is hanging, use the second instance to break into the process and examine the call stack of the UI thread. Usually the namespaces on the call stack can give you some clue as to what is happening.

Unless it's being caused by the garbage collector, than that's much more complicated to diagnose.

Humm, just sat down over lunch to try exactly that, but of course it's not hanging for anywhere near as long now. It was very repeatable this morning, but then not so much now - frustrating.

The delays seem longer when a debugger isn't attached, while I may be seeing patterns where there aren't any, I'm not sure: when I detach, it really does feel like it's taking longer/

When I try to break the debugger, it either says it's all native code, doesn't actually break (says Running but break icon is disabled), or doesn't break fast enough (hangs are now < 1sec but still noticeable).

Is there anything else I can try to narrow it down perhaps?

It's quite possible this is being caused by garbage collection in the IDE process.

Basically, the GC has the power to pause the process for entire seconds at a time to perform heap compactions. This happens longer and more frequently when there is high memory traffic in the process, which is basically caused by code within the process allocating and deallocating objects.

In such a situation, it's hard to squarely place blame on anything running within the IDE, because every package contributes. Every version of VS gets bigger and hungrier, and allocates more objects. If you're using other 3rd party tools (i.e. Resharper, Coderush, etc), then this will also significantly contribute to memory traffic.

The January 2015 release of NCrunch added a feature that hosts the NCrunch engine outside the IDE process. The primary reason for this was to stop (or severely limit) NCrunch from contributing to memory traffic in the IDE process. As long as you have your 'Engine hosting strategy' set to host the engine in a satellite process, NCrunch should contribute very little in the way of memory pressure as its footprint in the IDE is limited only to basic UI and synchronisation code.

Problems related to memory traffic and GC compactions can be hard to pin down by usage patterns, because they aren't usually tied to the tasks being performed in the process at the time. They're more related to aggregations of complex interactions deep down in the platform itself. You could get 10 minutes of clean running, followed by 20 minutes of frustration and appalling lag.

It can be possible to monitor the time the process spends in GC collection using perfmon.

I recommend looking at ways to lighten the load on your IDE. Consider turning off features or other packages to see what helps.