Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Huge slowdowns on threaded operations when debugger attached (macOS) #18705
When debugging our application (with attached debugger, no breakpoints), performance can drop to a point it becomes frustrating to do anything. On occasion we are also seeing OS level hard locking for seconds to minutes, which may be related.
Reproducible in both VSCode and Jetbrains Rider. This is exclusive to netcore (2.0 and 2.1) – does not occur under mono or net471 runtime environments. It also seems limited to macOS as I have not been able to reproduce on windows.
This can easily be reproduced on our game framework project: https://github.com/ppy/osu-framework (building should require not extra steps beyond checking it out).
Testing with debugger attached should drop to less than 1fps while it is easy to maintain hundreds without a debugger attached.
I've been trying to reproduce this with a more isolated test case but have not succeeded yet. Some pointers on moving forward in diagnosing this issue would be appreciated!
Hiya! We've been looking into resolving this issue since it's very critical for us.
Just recently we've noticed that
Here's a simple test:
On Windows this takes ~0.1ms per call (in a VM), and on macOS it takes ~2.6ms per call.
Since this function is called very readily through iterations of the async state machine, I believe this may provide some insight into why debugging performance is pretty poor.
@mikem8361 - I think the next step would be to do some native profiling of the debugger and determine where it spends its time. You could also do a comparison with something like:
If I had to make a guess, I wouldn't be surprised if all debugger events are slow on macOS, not only the custom notifications. Custom Notification just happens to be one of the debugger scenarios that can generate a high rate of debugger notifications which would expose the poor performance.
In terms of fixing it one approach is probably to address whatever the performance bottleneck is once it is identified via profiling. A second option is that we could implement a debuggee-side cache for the custom notification filter. Most of the time VS doesn't enable the custom notifications but rather than detecting this immediately in the debuggee, instead the runtime suspends, sends the notification to the debugger, then DBI determines nothing is listening to the event and resumes without having done any work.
Haven't had time to go into a deeper investigation yet (will probably do so on the weekend), but a quick sampling reveals the following (using
And yes, I can confirm that
I would like to add that we've seen the same behaviour on Linux. Debugging our application is extremely slow on Linux and fast on Windows.
Using your small repo, I got the following results:
On Windows: 465 ms (0.0465 ms per call)
Tried on Ubuntu 1804 and 1604 with .Net SDK 2.1.401, Runtime Version: 2.1.3 Commit: 124038c13e
The application makes extensive use of async/await and tasks. This is often on the call stack if you randomly break: