When an edit made in some C# file NCrunch's build step can take up to 5 seconds. You can reproduce this with a simple solution containing only one project and one C# file and it does not have to be a test project. A simple library is enough. Just try duplicating Console.WriteLine(); until you hit the issue. There is no issue on Visual Studio 2019. I am using Visual Studio 17.0.0 RC2 (same problem on RC1) and NCrunch 4.10.0.6
Here is a GIF illustrating the issue: https://imgur.com/a/e40DvWU
When a test is present and is run in response to changes made in the code, NCrunch will track and report performance details in the 'Execution Steps' tab in the Tests Window. There is a toolbar option allowing you to export the contents of this tab.
Do you think you could get me an export containing the details of the sluggish behaviour and copy/paste it here? Maybe this will give us a path to resolving the problem.
Edit: Scratch that, I've got it to happen. Will update you when I know more.
I've taken a quick look at the data immediately available to me. It looks like this is in the platform itself.
Basically, the first time MSBuild is invoked for a process, it's doing something very expensive internally. When invoked from the command line, it doesn't do this, so maybe there's a switch we can throw on this somewhere. I'll take a deeper look to see what kind of options are available.
There is a way you can reduce the impact of this problem. Adjust your 'Max number of test processes to pool' setting to a higher number. This setting also affects the process pool size for build processes, which will be re-used by NCrunch if they are available in the pool. When build processes are re-used by NCrunch, they seem to perform OK.
Thanks for quick response, but the workaround did not work for me.
By the way, seems like there is a pattern to this. I get this slowness consistently on every 5th edit I make.
I'm wondering if it might be possible to get more information about why the NCrunch build host is being recycled for your solution every 5 times the code is changed.
I can't reproduce such an issue on my side, and this seems to be the central concern around the performance, as the first time MSBuild is initialised, there is a very significant loss in build performance.
Are you able to submit a bug report for me after you've had the 5 second delay happen to you following a code change in your test solution? Please don't include the first build for this as we can be sure that one will be slow (and there may be nothing we can do about it). I'm more concerned about builds that are slow after we've had the initial spin-up.
I have submitted a bug report via Visual Studio. Description contains the link to this page. The slowness is on build that started at 17:37:25.1788. I've waited a few seconds between consecutive runs to be able to differentiate them more easily. There is a suspicious entry on UILogData file at line 7242:
[PID:26280 17:37:25.5538 LocalBuildTask-61] Process could not be found in pool with signature matching: [ProcessSignature:
Compiler
nCrunch.Compiler.RemoteBuildRunner
C:\Users\yusuf\AppData\Local\NCrunch\BuildSystem\26280\VS2022\nCrunch.BuildHost462.x64.exe.config
x64
(local)
nCrunch.Core.ProcessManagement.DefaultProcessLoader
Framework462
]
Thanks for sending through the log file. The problem looks to be here:
[PID:26280 17:37:10.9448 LocalBuildTask-64] Process 352e108f22ab462ea5f5759a9c4cc54f with system Id 32748 has 126070784 bytes in use, checking against a configured memory limit of 125000000
[PID:26280 17:37:10.9448 LocalBuildTask-64] Process 352e108f22ab462ea5f5759a9c4cc54f has exceeded its memory limit and will be terminated
I recommend increasing your build process memory limit. I'm going to increase the default value for it in the next build of NCrunch, as it seems that VS2022 tends to eat a bit more.
Edit: It looks like the build system is leaking memory, which is what's causing the memory limits to kick in. We're using an identical system for VS2019 and we're not leaking there, so most likely it's in the platform. I'm looking at options to see what we can do here. For now, I recommend increasing your memory limit to something high to reduce the number of process recycles. Don't turn it off, or you'll risk running out of memory.