Hi, thanks for sharing this issue.

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).

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.