After enough usage, it seems like the performance of NCrunch starts to wither. Right now, Resharper can build and test in a second. NCrunch takes nearly a minute.

Is there a way to refresh my NCrunch instance so I can get the original performance and fall in love with it all over, again?

Do you mean this?

https://www.ncrunch.net/...rack-engine-performance

I think I don't need to do anything, anymore, right?

That is definitely not normal behaviour. Assuming you're reviewing the 'Execution Steps' tab in the Tests Window, what sort of times are you seeing for the instrumentation and post processing of the assembly? Does this step make up a significant share of the time being lost?

Something interesting to try: Once your build has finished for a project that is taking too long to build, try right-clicking on the project in the Tests Window, then going Advanced->Browse to workspace. Look for the generated .proj file inside the NCrunch workspace, clear out the derived files in the bin/obj directories, then run msbuild.exe against this project and time it to see how long it takes. If this takes longer than it should (i.e. the same as NCrunch does), then we'll know the problem is something in the build itself. If it's fast, then we'll know the problem is something to do with how NCrunch is interacting with your build.

Is there any chance you could grab an export of the Execution Steps for a typical example of this? There's an option on the toolbar that should allow you to export it to CSV. You can then submit this through the NCrunch contact form.

The acquisition of a workspace can involve the building of the workspace on disk. This includes the copying of all files within a project into a separate area where they can be built/tested in isolation. If you have a large project with many small files included, this can be an expensive operation, especially if you're running on an older HDD. The good news is that once enough workspaces have been built to support the operation of the engine, it shouldn't build any more of them and it should just re-use the ones that it has. You can tell the difference in the Execution Steps when it's building vs reusing by examining the task involved - if it needs to build a new workspace, there should be an entry for 'Build new workspace'.

3 seconds spent establishing a host process is unusual. Is there a particular step inside this that is taking an unusual amount of time?

Note that like the workspaces, NCrunch will only allocate new host processes when it needs to and will prefer to re-use existing ones where it can. This means that after you've spun things a little, you might find this bottleneck also drops off considerably.

Thanks for sending through the report. I didn't see anything necessarily unusual in the report times other than the fact that they're generally fairly slow, especially around I/O actions. Probably the bottleneck across builds is your HDD/SSD.

The construction of workspaces and instrumentation of assemblies are within normal proportions to the time taken to execute MSBuild, which is essentially a benchmark for us as MSBuild is an external that we can't really change.

Reading through your initial comments, you mentioned that other runners can build and run the tests in about a second, while NCrunch takes upwards of 30 seconds. Given the times in the report you've shown me, this would suggest that NCrunch is building more projects than would be needed to run your tests. Generally, the building of projects should be limited to only the projects that have changed unless the 'Copy reference assemblies to workspace' setting has been turned on, or you're using a framework of some kind that causes NCrunch to implicitly turn this on.

Are you seeing whole build chains appearing when you make a change? Or is NCrunch only building the changed assembly?

I've uncovered something that is helpful to me and might be helpful to you, @Remco.

https://github.com/Azure...re-Functions/issues/789

I actually think that incident is ill-named and the original name (it builds every time) is more appropriate. It's not just that you can't incrementally build an Azure Functions app. It's that you cannot incrementally build _anything_ that depends on an Azure Functions app.

For my own part, I was already refactoring my system into many assemblies to facilitate incremental building. Soon, my unit tests assembly will have no coupling (direct or indirect) to my Azure Functions app. I'm also working on a PR to fix that problem for them.

However, this is a heads up for you. If you haven't already warned people that tests which depend on an Azure Functions app will do a full build of the functions app plus recompile all its dependents, you may want to do so.

I'll let you know if my decoupling effort really resolves my performance issue but I'm already quite confident it will.