Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

2 Pages<12
serious typing lag when running NCrunch in VS2019
NeilMacMullen
#21 Posted : Friday, August 9, 2019 6:15:40 PM(UTC)
Rank: Member

Groups: Registered
Joined: 12/15/2016(UTC)
Posts: 13
Location: United Kingdom

Thanks: 7 times
Was thanked: 4 time(s) in 4 post(s)
Quote:
>Intellisense tends to be quite hungry in general.


Indeed and I have Resharper installed which doesn't help! Nevertheless...

Quote:
>Can you confirm whether this is better when NCrunch is disabled?


Alas, it is -I can definitely say that enabling Ncrunch affects keyboard (and hence intellisense) responsiveness. Following Der-albert's scientific approach ;-)
I basically mash the keyboard as fast as I can typing 30-40 random characters. Note that the auto-repeat rate on my keyboard is not sufficient to reproduce this clearly so "holding down the comment key" doesn't really do it.



- With Ncrunch enabled, after I stop typing, it takes a second or so for the buffered characters to 'catch up' and be displayed on the screen.
- With Ncrunch disabled, there's no such lag.

Note that I'm typing in a file/project that is quite deep in the dependency tree but the particular method I am typing in has no covering tests (white dots in border). When I stop typing, the Ncrunch test window says "217 tests are queued for execution" but then immediately says that 1 project is failing to build (because I've just typed garbage). If I remove the garbage characters, the project then rebuilds and tests are run. (I mention this only in case it's relevant - I would have expected that modifying the method wouldn't cause any tests to run at all?) Perhaps it's also relevant that I have ~70 projects in the solution including a C++ dll which is tested via a C# library with tests running in isolated mode because of static state in the dll?


Quote:
>If so, we might need to work through the big list of questions earlier in this thread to try and narrow this one down.


Ok, here goes....


Quote:
- Does the problem appear when NCrunch is running at full speed with all its tool windows closed?


Yes

Quote:
- Does the problem appear when NCrunch is running at full speed with all its tool windows closed and the 'instrument output assembly' setting set to 'False' for your entire solution?


Switching "instrument output assembly" to false significantly improves performance to the point where there is very little type-ahead.

Quote:
- What if you set NCrunch to the 'Execute tests manually' engine mode so it only runs builds?


Switching "instrument output assembly" back to true and "execute tests manually", the problem is still there.

Quote:
- What if you set the 'Max number of processing threads' setting to 1?


Switching "instrument output assembly" back to true and setting Max number of processing threads to 1 significantly improves UI responsiveness

Quote:
- Do you have any other test solution of roughly similar size (3rd party open source is OK) that you can try testing with to see if the problem is specific to your solution?


Unfortunately not though happy to try one if you have a suggestion.


Quote:
Other things to check:

- Do you have 'Log Verbosity' set to anything other than 'Summary'?


No

Quote:
- Can you check for hidden warnings in the NCrunch Tests Window?

The only one I have is for a UI (non-test project)...

Quote:
It has been detected that this component is referencing assemblies within the build output directories of projects within this solution. It is strongly recommended that assemblies are referenced from a directory location that is not subject to disruption from the build process.

Directly referencing assemblies that are updated, copied or manipulated by the build of projects in this solution will create implicit build dependencies that cannot be tracked by NCrunch or MSBuild. This can result in inconsistent build behaviour patterns and code versioning issues. It can also cause problems when trying to execute a clean build of the solution after it is checked out of a source control system.

The following assembly references have triggered this warning:
D:\work\Backend\CSharp\Applications\UI\DeviceInvestigator\bin\Debug\Microsoft.AspNetCore.Components.dll




Quote:
- Are you running any other VS plugins other than NCrunch and ReSharper?


OzCode

Quote:
- Are you running an antivirus of any kind? Does disabling it make any difference?


Windows Defender. Solution and Ncrunch workspaces areas are in the exclusion list.

Quote:

- If you perform the comment key test while you have Windows Task Manager open to the CPU page, do you notice any of the cores becoming fully locked at 100%?


Do you mean locked continuously? During typing there is a brief period of a few seconds when all 8 cores appear to hit 100% but they then recover after typing stops.


Unfortunately I'm on vacation for a few days so can't run any further tests for a while. I should also be honest and say that I can't be certain the lag is new though my subject impression is that it was introduced with the latest version. However both Resharper and Ozcode were updated at very close to the same time so it is possible one of those is the culprit.
Remco
#22 Posted : Friday, August 9, 2019 11:53:21 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,759

Thanks: 745 times
Was thanked: 956 time(s) in 911 post(s)
Thanks for taking the time to go into so much detail on this issue. With the information you've provided, my best empirical analysis is that the issue is caused by overall resource load on your machine interfering with the responsiveness of the IDE.

NCrunch makes use of a O/S level feature called processor affinity, which allows its sub-processes to run on separate CPU cores to VS. In theory, this allows us to max out a part of your CPU while reserving another part for the VS experience.

In practice, it's not perfect. Hyper-threading can cause some level of interference across the affinity wall. There is also the risk of some sub-processes not sticking with the affinity pattern. One of the problems we've had the most trouble with is the Roslyn compiler, as it actually gets hosted in the O/S as a singleton EXE that has instructions passed to it through IPC. This singleton is shared between both VS and NCrunch, and there is always the chance that it can spawn other child processes depending on the needs of the development platform. There is also the risk of other sub-processes being launched from the build system with complex interactions that are outside of our control.

Finally, to my knowledge, there is no way to set such a barrier in place for I/O operations. This means that if Visual Studio has some kind of I/O action that might lock its primary thread (even for the slightest amount of time), and your SSD/HDD is oversubscribed with a range of background build tasks, this can then impact the IDE performance. The building of projects on disk is a very I/O intensive process.

There's several ways you can mitigate this:
- Try running with less background processes (i.e. set the 'Max number of processing threads' to a lower value)
- Consider moving your workspace base path to a RAM disk if you have the memory resources
- Make sure your NCrunch CPU core assignment settings don't split a physical CPU across the barrier (i.e. split your cores in even numbers if you have hyper-threading)
- Consider using the sliding build delay setting
- Avoid working with a large number of files open in VS at one time
- Distributed processing

Finally, I've dreaded the day where I would need to say this, but 8 logical CPU cores (4 physical?) running under VS2019 on a solution with 70 projects is probably going to be a stretch for hardware. Successive versions of Visual Studio have been eating more and more CPU, with many of the optimisation strategies employed by the teams at MS being focused on making more and more use of background cores. This means that NCrunch is being pushed into a progressively smaller corner to work from. Under VS2017 we observed a large solution needed at least 3 logical cores to avoid noticed loss in performance. Under VS2019 we're up to 4. Large chunks of code and complex toolsets may push that number even higher. If poor performance is impacting your work efficiency, it may be time to consider upgrading your hardware or pushing some work off to a remote machine using distributed processing.
1 user thanked Remco for this useful post.
NeilMacMullen on 8/22/2019(UTC)
NeilMacMullen
#23 Posted : Thursday, August 22, 2019 10:34:47 AM(UTC)
Rank: Member

Groups: Registered
Joined: 12/15/2016(UTC)
Posts: 13
Location: United Kingdom

Thanks: 7 times
Was thanked: 4 time(s) in 4 post(s)
Thanks Remco. I'll definitely take a look at the distributed processing. :-)
MatthewSteeples
#24 Posted : Thursday, August 22, 2019 10:41:55 AM(UTC)
Rank: Advanced Member

Groups: Registered
Joined: 10/28/2014(UTC)
Posts: 89
Location: United Kingdom

Thanks: 5 times
Was thanked: 12 time(s) in 10 post(s)
Can definitely recommend the distributed processing. Our lower powered devices have local processing disabled and rely solely on grid nodes.

Remco: Is it possible to disable the affinity options (is it as simple as putting all of my cores in both options)? As you've configured the processes properly with priority etc, I'd rather rely on the OS to do the scheduling
1 user thanked MatthewSteeples for this useful post.
NeilMacMullen on 8/23/2019(UTC)
Remco
#25 Posted : Thursday, August 22, 2019 10:46:49 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,759

Thanks: 745 times
Was thanked: 956 time(s) in 911 post(s)
MatthewSteeples;13789 wrote:

Remco: Is it possible to disable the affinity options (is it as simple as putting all of my cores in both options)? As you've configured the processes properly with priority etc, I'd rather rely on the OS to do the scheduling


Yes, absolutely. Using the configuration settings you can choose which cores to assign to both VS and NCrunch, so it's possible to just assign ALL cores to both systems.

On grid nodes, the affinity system isn't used as it's assumed that the node doesn't need to maintain a workable UI.
Users browsing this topic
Guest
2 Pages<12
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.083 seconds.