Sorry, but there have been no actions to follow up on this, as so far we haven't been able to reproduce or isolate any issue like this.

The problem here is that a slow speed in VS can be caused by a near infinite number of things, most of which NCrunch has nothing to do with.

NCrunch is now designed to keep all its processing outside the VS process, this means that if there is a loss of performance in VS that coincides with heavy activity in the NCrunch engine, then the only way this could really be related is through overconsumption of resources. For example, you have the engine turned up too high and the entire system doesn't have enough resources to maintain performance in the UI for any application.

Hi,

My whole team is experiencing this issue. When this typing lag occurs, the CPU usage on the cores assigned to NCrunch maxes out at 100%. Despite the engine separation from Visual Studio, this effectively locks up the IDE completely.

The typing lag has become so bad that many of us have resorted to turning off NCrunch completely while developing.

Up until upgrading to Visual Studio 2015, our experience with NCrunch had been superb and we had become big advocates. Our solution has not changed significantly, so we can only assume that the underlying issue is NCrunch's integration with Visual Studio 2015.

None of the recommendations listed in this thread have helped. We are running NCrunch in Visual Studio 2015 with the same settings that we used in Visual Studio 2013 without issues.

Could you please advise on what is being done to resolve this? We're running out of options and may have to confront giving up on NCrunch completely. This would be very sad day for us, having used this superb tool for a good few years...

Thanks.

Hi Remco,

Thank you very much for the quick reply.

To answer your questions:

Has the NCrunch given you any warnings about your environment? Particularly, anything about the Git Source Control Provider?
I haven't noticed any warnings from NCrunch at all.

Do you find that the performance issue is following any particular pattern?
The issue appears whenever NCrunch is turned on. The typing lag happens on even the most seemingly-innocuous thing, such as when typing a comment. It happens on both unit test code and application code. It appears to be at its worst when NCrunch is building the solution.

For example, does it take a while before it appears during a session?
Trying it this morning after a restart, the issue appears as soon as NCrunch is turned on. My previous experience suggests that it does seem to get worse throughout the day.

Is IDE memory usage very high when it happens?
Not particularly. Although as suggested in my previous answer, the memory usage does creep up throughout the day. I am tending to suspect that this is Visual Studio 2015 misbehaving rather than NCrunch, as we have been regularly turning NCrunch off throughout the day.

Does it seem to appear intermittently then suddenly disappear, only to reappear a minute or so later?
The typing lag does fluctuate in its intensity. Sometimes typing is fairly fluid, sometimes it lags for half a second, and sometimes it lags for up to a couple of seconds. Pretty distracting, as I’m sure you can imagine. However, the only sure way to make it disappear completely is to turn off NCrunch altogether. Turning it back on brings the issue back.

Does it appear on ALL solutions, or just one in particular?
It seems to happen on all of our production solutions, however it should be said that most of our solutions share a common core of projects which are lugged around in each solution. The problem doesn't appear when creating a new solution that has very few files in it, so I suspect that having large solutions makes the problems worse. Having said that though, our solutions are not exactly massive: we have circa 12 projects, including unit test projects. We do have over 10,000 unit tests, which I suppose is testament to how much we were using NCrunch. But these are certainly not the biggest solutions I’ve ever seen. In addition, speaking to a colleague who runs his own business developing a much smaller solution, he says he experiences the same issue at home too.

Furthermore regarding our solutions, we have done some tuning to try to ensure the problem isn't being caused by something we're doing. We've removed an issue that was causing one or two of our projects to rebuild everytime, for example. But again, the fact that none of these issues were apparent with the same solutions in Visual Studio 2013 makes me suspect it's something to with the IDE integration.

I know there have been some complaints about the performance of the Roslyn compiler, and other complaints related to memory consumption in the IDE. Could it be that NCrunch is simply exacerbating some of the underlying issues in the IDE?

Thanks again.

I've been doing a bit more thinking about possible causes of performance problems under VS2015.

Since you've mentioned that the perf issues seem to be related to build activity and started only after upgrading to VS2015, I'm wondering if you may be able to take a look at the processor consumption of VBCSCompiler.exe while NCrunch is running.

This particular process is newly introduced by Roslyn, and because it isn't under NCrunch's direct control, it doesn't have its processing priority set to Low/Background ... This is actually a bad thing, as it could result in build activity stealing CPU away from Visual Studio. Something worth trying is to manually set the process priority of this service to 'Low' after you've noticed it starting up in your task manager.

I think it may be worth disabling the VBCSCompiler process to see if this resolves the issue.

A bit of background on this process: VBCSCompiler.exe was introduced as part of Roslyn. It basically executes the core compiler code and because it is quite an expensive process to initialise, Roslyn is designed to keep it resident and share it between compile runs. For standard IDE builds, this works great because it saves Roslyn from needing to tear down and reinitialise between every build of every project. However, there is a drawback here in that the process is outside of the direct control of NCrunch which makes hard to manage its CPU consumption. It would not be a surprise to me if this process is the cause of your performance issues.

It's possible to turn off the use of this process with the 'UseSharedCompilation' build property, i.e:

<PropertyGroup>
<UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>

I would suggest setting this as an environment variable so that the process is completely disabled system-wide. MSBuild cleanly substitutes environment variables for build properties when it initialises, so by doing this we can shut down the VBCSCompiler.exe process entirely and have Roslyn execute its code within a normal MSBuild host. You can add the environment variable to your standard user/system profile, UseSharedCompilation=false

Note that doing this will significantly increase your build times. I don't really recommend running with it long term, but it might help us to determine with certainty the source of your performance issues.

Thanks for confirming this. I have a theory here now on what is happening here.

The VBCSCompiler.exe process is a 'shared' process that is started by the first invocation to MSBuild/CSC/VBC, basically when a project gets built by Roslyn.

This process stays resident for a period of time. If it's left idle long enough, it will self-terminate. I'm not sure what the threshold is for this, but I presume upwards of 15 minutes.

The process is used to perform ALL compile steps for any code compiled on the machine it's running on, and it is not externally managed in any way (i.e. if you shut down VS, the process lives on).

If the process is launched outside the context of NCrunch (i.e. your first build on the machine is done in VS or using a different tool), it is launched with the CPU affinity and processing prioritisation of the calling process, which would normally allow it to run under ALL CPUs on the system and at standard priority. For NCrunch, this is a really bad thing because it means the process can steal CPU away from VS. I expect that on a lower end system (or higher end system running at full capacity) you will see a performance issue appear as a result of this.

If the VBCSCompiler process is launched by NCrunch (i.e. your first build on the machine is performed by NCrunch), it will inherit the processing attributes of NCrunch itself, and it should steer clear of the CPU cores that have been reserved for VS.

So basically, you may be able to avoid the performance issue entirely by ensuring your first build is performed by NCrunch. If you leave your desk for a period of time and come back, make sure that NCrunch is used for the next build so that the process always has the correct processing attributes.

I have a fix in the works for this as part of the 2.24 release, which I'm hoping to kick out within the next couple of weeks. If you're interested in trying the above, please let me know how it goes.

Hi! What kind of result do you get if you make sure NCrunch is the first tool to run a build on your machine (as per the above post)? As long as NCrunch is responsible for spawning the VBCSCompiler.exe process, it should set the processor affinity for this process correctly and negate any CPU issues.

Killing the VBCSCompiler.exe process will also reset it. If you do this while NCrunch is running, NCrunch will respawn the process with the correct processing attributes. So in short, you should be able to suppress this problem when it appears by killing the VBCSCompiler.exe process using task manager.

Hi, my company's seat licensing expired earlier this month so I can't upgrade to this version to rectify this issue.
This bug has been open for 7 months so there has been adequate time to resolve this during our licensing period, to meet SLA expectations.
Can you arrange some way for us to take advantage of this upgrade as we have spent a significant amount on licensing and would expect the software to be fit for purpose.

Kind Regards.

I think I'm having this too. I'm using VS15 update 3 and just installed NCrunch 2.26.0.1
My theory is that it's not VBCSCompiler.exe. When I am fast enough to switch to Task Manager, I see devenv.exe as the primary cause of the CPU usage.
I've tried changing the CPU core assignment settings without luck.

The odd thing is that instantly after disabling NCrunch the perf comes back. And according to Task Manager, it seems to be VS. Really odd.

Thanks @Remco. No, no warnings about the git plugin. I do think that was the issue:
[img=https://www.dropbox.com/s/rbgddyr6bhxtt7a/Screenshot%202016-08-23%2016.16.26.png?dl=1]that darn Git plugin[/img]

Turned this off again and the speed seems to be picking up. A good test is tyuing out a long chain of methods and watching the intellisense lag and CPU usage by devenv.exe.