Debugger siezes up when many websocket connections are opened

[sossee2]

Not sure if exaxtly the same issue but the same symptoms with the exception that this happens reliably as soon as I fire up the hundred or so client websocket connections in my app. App slows to a crawl, Diag tools screen almost stops and many threads are in "System.Private.CoreLib.dll!System.Diagnostics.Debugger.NotifyOfCrossThreadDependencySlow()" as per the screenshot. It started happening following my port from .NET Framework to .NET5.0 (latest GA build)

Originally posted by @sossee2 in #42375 (comment)

• The app appears to run fine without the debugger attached.
• With debugger attached the app appears to get slower and slower (exponentially) with more and more websockets added.

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Not sure if exaxtly the same issue but the same symptoms with the exception that this happens reliably as soon as I fire up the hundred or so client websocket connections in my app. App slows to a crawl, Diag tools screen almost stops and many threads are in "System.Private.CoreLib.dll!System.Diagnostics.Debugger.NotifyOfCrossThreadDependencySlow()" as per the screenshot. It started happening following my port from .NET Framework to .NET5.0 (latest GA build)

Originally posted by @sossee2 in #42375 (comment)

Author:	sossee2
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

Tagging subscribers to this area: @tommcdon, @krwq
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Not sure if exaxtly the same issue but the same symptoms with the exception that this happens reliably as soon as I fire up the hundred or so client websocket connections in my app. App slows to a crawl, Diag tools screen almost stops and many threads are in "System.Private.CoreLib.dll!System.Diagnostics.Debugger.NotifyOfCrossThreadDependencySlow()" as per the screenshot. It started happening following my port from .NET Framework to .NET5.0 (latest GA build)

Originally posted by @sossee2 in #42375 (comment)

• The app appears to run fine without the debugger attached.
• With debugger attached the app appears to get slower and slower (exponentially) with more and more websockets added.

Author:	sossee2
Assignees:	-
Labels:	area-System.Diagnostics, untriaged
Milestone:	-

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Not sure if exaxtly the same issue but the same symptoms with the exception that this happens reliably as soon as I fire up the hundred or so client websocket connections in my app. App slows to a crawl, Diag tools screen almost stops and many threads are in "System.Private.CoreLib.dll!System.Diagnostics.Debugger.NotifyOfCrossThreadDependencySlow()" as per the screenshot. It started happening following my port from .NET Framework to .NET5.0 (latest GA build)

Originally posted by @sossee2 in #42375 (comment)

• The app appears to run fine without the debugger attached.
• With debugger attached the app appears to get slower and slower (exponentially) with more and more websockets added.

Author:	sossee2
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[hoyosjs]

This looks like a case of #38736

[sossee2]

This looks like a case of #38736

Thanks for the link. Are there any suggested workarounds to this?

[hoyosjs]

None that I can think of now really. The debugger uses the cross-thread dependency notifications very often (evaluation of properties for example in the watch window) and we always fire them. We are talking about adding something, but if won't land until at least .NET 6. Looping @dotnet/dotnet-diag in case they have any ideas.

[sossee2]

I tried adding [DebuggerStepThrough] attribute to the websocket wrapper however that didn't seem to have an impact. Given I don't need to debug the class that is doing most of the task based work which I believe to be the source of this issue, is there a workaround based on that?

[hoyosjs]

No. This is all in the general debugger infrastructure. If we didn't have said notifications, we could end up in deadlock situations when evaluating functions under the debugger. The problem is there's no mechanism to turn it off so that it only happens during evaluations - it's always on. This is actually a notorious perf hit when running under the debugger and there's large amounts of tasks completing for example.

[noahfalk]

You said this problem occurs when debugging in .NET 5 but it doesn't occur when debugging in .NET Framework right? Is the .NET Framework app also using similar web socket code with similar load or did something change there as well? I ask because this performance characteristic in the debugger has existed for a long time, including on .NET Framework. The fact that it wasn't causing you grief before suggests something else changed. We don't yet know what it is, but my first guess is that the app might be executing code containing NotifyOfCrossThreadDependencySlow() far more frequently in .NET 5 than it did on Framework because something is generating Tasks much more frequently. For example if the original app was generating 100 Tasks/sec and the ported code is generating 10,000 Tasks/sec then a previously trivial debugger perf overhead might now be a large one. Comparing a CPU trace of the .NET Framework app to the .NET 5 app while running under the debugger might be able to identify where the discrepancy is.

Are there any suggested workarounds to this?

By no means do I think this is an easy or pleasant workaround, but just to put all options on the table theoretically you could build a private copy of System.Private.CoreLib.dll with this line commented out to use for development purposes. Depending on your app this might make VS more prone to having function evaluations that it can't abort. If that did occur you could additionally disable implicit function evaluation in the VS debugger settings window to mitigate it.