Hi,
When typing sometimes VS lags and shows a message that an extension is slowing down the performance of VS.
Most of the time it blames R#, so I've created an issue on the R# issue tracker, but the snapshot I've provided seems to show that NCrunch is involved as well, can you may have a look at:
https://youtrack.jetbrains.com/issue/RSRP-476636 (at least the last comments created today (10.12.2019) are relevant).
NCrunch: 4.2.0.5 (but it also happened on 4.2.0.4, 4.2.0.2, 4.2.0.x, and the official one (4.1.x.x)
The snapshots you've provided suggest that the issue is appearing in the code we use to show coverage markers in the editor window. We haven't touched this code for a few years now, though I expect there's a possibility you might have found an edge case where it doesn't work as quickly as we'd like it to. Do you have any source files open on your screen of an unusual size? (i.e. many thousands of lines).
Note here the alarming time this particular stack takes (nearly 10 seconds!!). Yet despite NCrunch eating 3.8s of this, it isn't responsible for the entire lag here:
3.66% HandlePossibleTypingCommand • 9,649 ms • Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.RenameCommandHandler.HandlePossibleTypingCommand(EditorCommandArgs, Action, Action)
3.66% <Execute>b__0 • 9,648 ms • Microsoft.VisualStudio.UI.Text.Commanding.Implementation.EditorCommandHandlerService+<>c__DisplayClass13_1`1.<Execute>b__0()
1.45% \u0002 • 3,819 ms • nCrunch.WpfUI.WpfEditorWindow.\u0002(Object, TextViewLayoutChangedEventArgs)
1.45% \u0006 • 3,818 ms • nCrunch.WpfUI.WpfEditorWindow.\u0006()
► 1.45% \u000E • 3,818 ms • nCrunch.WpfUI.WpfEditorWindow.\u000E()
This would suggest that even if we removed our code here entirely, the problem would still exist. I think this is caused by an insane amount of data being passed through here, or maybe a performance issue of a broader kind (i.e. CPU starvation, memory traffic, heap compactions, etc).
The snapshots you've provided suggest that the issue is appearing in the code we use to show coverage markers in the editor window. We haven't touched this code for a few years now, though I expect there's a possibility you might have found an edge case where it doesn't work as quickly as we'd like it to. Do you have any source files open on your screen of an unusual size? (i.e. many thousands of lines).
Note here the alarming time this particular stack takes (nearly 10 seconds!!). Yet despite NCrunch eating 3.8s of this, it isn't responsible for the entire lag here:
3.66% HandlePossibleTypingCommand • 9,649 ms • Microsoft.CodeAnalysis.Editor.Implementation.InlineRename.RenameCommandHandler.HandlePossibleTypingCommand(EditorCommandArgs, Action, Action)
3.66% <Execute>b__0 • 9,648 ms • Microsoft.VisualStudio.UI.Text.Commanding.Implementation.EditorCommandHandlerService+<>c__DisplayClass13_1`1.<Execute>b__0()
1.45% \u0002 • 3,819 ms • nCrunch.WpfUI.WpfEditorWindow.\u0002(Object, TextViewLayoutChangedEventArgs)
1.45% \u0006 • 3,818 ms • nCrunch.WpfUI.WpfEditorWindow.\u0006()
► 1.45% \u000E • 3,818 ms • nCrunch.WpfUI.WpfEditorWindow.\u000E()
This would suggest that even if we removed our code here entirely, the problem would still exist. I think this is caused by an insane amount of data being passed through here, or maybe a performance issue of a broader kind (i.e. CPU starvation, memory traffic, heap compactions, etc).
Thx for your time.
I was typing in a C# File with about 100 or 200 lines of code, it seems, that ReSharpers ReSpeller Feature is the root cause, deactivating this feature helps, but there are still 3,8secs that is taken by NCrunch, is there anything I can do to mitigate that issue.
Unfortunately it's hard to reproduce
Thx for your time.
I was typing in a C# File with about 100 or 200 lines of code, it seems, that ReSharpers ReSpeller Feature is the root cause, deactivating this feature helps, but there are still 3,8secs that is taken by NCrunch, is there anything I can do to mitigate that issue.
Unfortunately it's hard to reproduce
Sadly, without a way to consistently reproduce the issue, I'm at a bit of a loss as to how to provide a fix for it or produce a workaround.
My suspicion is that something is not right inside your VS process. This could be caused by another VS package, or it may be resource based. Do you observe any resource constraints when using Task Manager? It might also be interesting to see how much time the IDE process is spending in garbage collection, which can be identified using perfmon.
Thx for your time.
I was typing in a C# File with about 100 or 200 lines of code, it seems, that ReSharpers ReSpeller Feature is the root cause, deactivating this feature helps, but there are still 3,8secs that is taken by NCrunch, is there anything I can do to mitigate that issue.
Unfortunately it's hard to reproduce
Sadly, without a way to consistently reproduce the issue, I'm at a bit of a loss as to how to provide a fix for it or produce a workaround.
My suspicion is that something is not right inside your VS process. This could be caused by another VS package, or it may be resource based. Do you observe any resource constraints when using Task Manager? It might also be interesting to see how much time the IDE process is spending in garbage collection, which can be identified using perfmon.
Thx for your support, I will report back if I'm able to reproduce the issue.