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

Notification

Icon
Error
VS2019: We've noticed that extension 'NCrunch for Visual Studio' is slowing typing performance
Options
Previous Topic Next Topic
cwain
#1 Posted : Tuesday, November 12, 2019 3:43:58 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/12/2019(UTC)
Posts: 4
Location: Denmark
For the past few months, I have experienced minor issues with NCrunch regarding slowing down typing in VS2019.

After update to NCrunch 4.1.0.1 I am receiving the "VS2019: We've noticed that extension 'NCrunch for Visual Studio' is slowing typing performance" warning in Visual Studio several times a day.

I have experimented with the new build engine and legacy build engine to see if that would change anything, but without luck.

The "Visual Studio Performance Manager" reports that "NCrunch for Visual Studio" "Adds 1260 miliseconds on average".


In hope this can be improved in a future version :)

/Michael
Back to top
Remco
#2 Posted : Tuesday, November 12, 2019 10:50:15 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Hi Michael,

Presently, we are aware of only one thing that can cause this.

Can you check if your 'Log to output window' setting is turned off?

The engine will usually give a performance warning about this, but it might have been hidden from you.
Back to top
cwain
#3 Posted : Wednesday, November 13, 2019 8:05:45 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/12/2019(UTC)
Posts: 4
Location: Denmark
Remco;14063 wrote:

Can you check if your 'Log to output window' setting is turned off?


This setting is already configured to "False".

NCrunch is configured for 2 CPU cores (VS configured for 6) with "Max number of processing threads" configured to "2".

In addition I am using a RAM-disk for both NCrunch and VS build paths.


/Michael
Back to top
Remco
#4 Posted : Wednesday, November 13, 2019 9:25:09 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Thanks for confirming this. Unfortunately, this means the problem is one that we haven't seen before.

Are you able to narrow down when the sluggishness happens? There's a fairly unscientific way you can assess this. Basically, hold down the comment key inside one of your code windows, and count the number of times your IDE visibly stutters while you write a full line of '/'. If all is functioning properly, there should be no visible stuttering.

This gives us a way to establish when the problem is appearing and when it isn't. Try doing this with NCrunch in the following states. This will help to establish what is surfacing the issue:

- When NCrunch is disabled
- When NCrunch is enabled, and set to manual mode
- As above, but with all NCrunch windows closed, and only one code window open
- When NCrunch is enabled, and there is a large test run in progress (hit the 'Run all tests' option and wait for a few seconds for some tests to start)
Back to top
cwain
#5 Posted : Wednesday, November 13, 2019 9:57:27 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/12/2019(UTC)
Posts: 4
Location: Denmark
It appears that the issue occurs when:

1) NCrunc enabled, and there are test run in progress
2) The (C#) code file somewhat large (issue did NOT occur in a file with 100 lines - issue occurred in a file with 1300 lines)


Further info: I have docked the "NCrunch Tests" window in the bottom of VS, and have it shown quite often. I have also started noticing a short lag when NCrunch are updating the icons in the VS code window (but that is somewhat understandable - and I may only be noticing now because I am more focused on the issue at the moment).


A possibly related issue, it appears that VS gets sluggish after some time - with a restart of VS fixing the issue (several times a day). When this issue occurs, the memory pressure of VS isn't alarming (0.8-1.3 GB) - and I cannot definitely say that it is caused by NCrunch - but the symptoms are very much like the ones one get with ReSharper where GC runs very often and this issue seems to happen more often lately with only NCrunch, OzCode and VS itself been updated.



/Michael
Back to top
Remco
#6 Posted : Wednesday, November 13, 2019 10:53:47 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Thanks Michael. This does help to narrow things down.

I'm wondering if this might be caused by general system lag triggered by overconsumption of the background tests. Do you have any tests in your solution that are particularly large? For example, anything that has a long running time and might interact with an external process (i.e. a database).

Also, can you confirm if you have your 'Engine hosting strategy' NCrunch configuration set to 'HostInsideIDE'? (if not, please don't turn this on)

Further, can you share the overall specifications of the machine you're running on, and the approx size of your codebase?
Back to top
 |  Edit by user
cwain
#7 Posted : Thursday, November 14, 2019 7:52:26 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 11/12/2019(UTC)
Posts: 4
Location: Denmark
Remco;14072 wrote:
Thanks Michael. This does help to narrow things down.

I'm wondering if this might be caused by general system lag triggered by overconsumption of the background tests. Do you have any tests in your solution that are particularly large? For example, anything that has a long running time and might interact with an external process (i.e. a database).


That depends on the definition of large. We have around 1100 tests, where around 100 are largish - but NCrunch does not report them as long running. They are large (1500+ LOC is not unusual) as we need to fake quite a bit - but none of them use any external resources / processes.

NCrunch hasn't had an issue until lately.

I have recently increased the number of threads for NCrunch from 1 to 2 - which of course double the workload - but I figured it was handled in satellite processes on dedicated cores - it shouldn't affect VS.

Remco;14072 wrote:
Also, can you confirm if you have your 'Engine hosting strategy' NCrunch configuration set to 'HostInsideIDE'? (if not, please don't turn this on)


No, this setting is set to "x64SatelliteProcess"

Remco;14072 wrote:
Further, can you share the overall specifications of the machine you're running on, and the approx size of your codebase?


Machine: i7-6700, 3.40 GHz, 4 cores (8 threads - 2 dedicated to NCrunch), 24 GB ram. I use RAM disk for both NCrunch and solution output directories in VS. Because of the RAM disks using 14 GB, there's 2 GB free with VS etc. running.

Solution: 57 projects (C#), around 70-80.000 LOC, 1100 unit tests.

VS-plugins installed:
R#, but not enabled (only when absolutely needed)
OzCode
Sandcastle Help File Builder
Atomineer
Roslynator
Visual Studio IntelliCode

One "issue" I have noticed (but may very well be wrong) is, that it seems that NCrunch with v4.1.0.1 seems somewhat more aggressive in determining whether or not a given unit test should run or not.

If(!) my memory serves me right, when I made a change to a lower level project - then NCrunch might only mark a few unit tests to be run - but with 4.x it is not unusual to see that almost all unit tests are marked for running (seems that all that are using the given assembly - which means that 1 minor change may result in 1000+ unit tests being marked for run).

Also, yesterday I had to enable R# for a few changes - which of course made the VS quite a bit slow (=usual issue with R#). After I disabled R# again, VS was continually "screaming" about NCrunch slowing things down - enough that I had to disable NCrunch. Even though I had around 30 files open in VS, the memory preasure was only around 1 GB at the time - but VS was lagging quite a bit. Disabling NCrunch fixed the lagging issue.

Do you think having NCrunch on a dedicated, external machine would solve the issue? I personally don't think so, as it seems to me that it could be the NCrunch's Roslyn plugin (which I guess NCrunch has?) that might be the cause of the problem I am experiencing.

/Michael
Back to top
Remco
#8 Posted : Thursday, November 14, 2019 11:20:25 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 7,123

Thanks: 957 times
Was thanked: 1286 time(s) in 1193 post(s)
Hi Michael,

Thanks for sharing these extra details.

Which engine mode do you usually work in? The default 'Run all tests automatically' will automatically queue ALL tests in the project scope when any change is detected (even a comment). The 'Run impacted tests automatically' mode is usually much more selective, though its ability to cut down the number of tests that need to re-run is heavily dependent on the structure of your code and nature of your tests.

As far as I know, VS blames plugins for responsiveness if it finds a plugin's namespace showing up in a stack trace extracted from the VS main thread when it takes too long to respond. This has been known to create false positives. If the problem is bad enough, it would be very interesting to try and extract this stack trace from your machine. One way this would be possible is by opening a second VS instance, then using the debugger in this instance to connect to the first VS instance. When the responsiveness becomes extremely bad, break in with the debugger and examine the stack trace for the main UI thread in the VS process. Try breaking in several times to see if you can identify a trend in what is being executed when the responsiveness is poor. Most likely, there is a single bottleneck. If you can copy/paste the stack trace here into the forum, we'll likely have some useful information to work from in identifying the source of the problem.

Another interesting thing worth testing (if the above doesn't work out), is to use perfmon.exe to check how much time the VS process is spending in garbage collection. You could have this running side-by-side with VS to see if there is any correlation between heap compactions and poor process performance. It may be that something in the VS process is trafficking vast amounts of memory and NCrunch is being blamed because it's the only plugin making use of the UI thread.

On a machine with 4x physical cores, having a separate grid node to perform the bulk of your processing is almost always worthwhile. If you have the option to do this, I highly recommend it.
Back to top
 |  Edit by user
Users browsing this topic
Guest
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.090 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download