Hi, thanks for posting!

Right now NCrunch doesn't really 'know' anything about the source code its compiling, so it isn't able to make intelligent decisions about whether a build should or should not be run based on a particular change being made. There are plans in V2 for features that I hope should alleviate this problem in a number of different ways. I understand that the build triggering could be made more efficient and I've been looking at ways to implement this (with the delayed trigger being one of several options).

Normally though, the background builds shouldn't be causing a noticeable lag in the IDE. Are you able to share any more details about the system you're working on? Is it a low-spec machine?


Cheers,

Remco

I suspect something that may be having an impact is the amount of I/O activity being caused by the NCrunch builds. From what you've described, you should have ample CPU resources to be able to run the builds in parallel. It may be that if you are running tests that are quite I/O heavy (or make use of a DBMS), then the builds are enough to overload the disk queue and cause interruption to VS activities that make use of I/O calls. If you have enough memory available on your machine, it may be worth looking into setting up a RAM disk to store your NCrunch workspaces on - this will prevent the builds from clogging up the system and should give you a big performance boost too.

Another option is to try reducing the 'Max number of processing threads' global configuration setting, as this will reduce the number of builds NCrunch is allowed to execute concurrently.

Thanks for the suggestion on the delay trigger - I'll continue to look at this as a long term option.


Cheers,

Remco

For anyone interested, the feature described above (a configurable delay trigger for NCrunch builds) has been introduced with the newly released version of NCrunch (v1.45), through the Sliding Build Delay global configuration setting.