based on this article:
I have the following suggestions:
1. “We have seen issues where traditional breakpoints become corrupted and are treated as function breakpoints which slows down debug startup”
either this can be stopped by the IDE from happening from the start, or on each repeating of a break point, a warning message box is displayed that informs the developer of the effects of adding multiple breakpoints with no needs.
2. the following windows:
Populating call stack information, Parallel Stacks Threads, Tasks, and GPU threads, the current stack frame
Evaluating expressions in any visible watch windows
Refreshing the contents of any other windows that could have changed while the application was running
Autos and Locals windows
Windows that refresh
Breakpoints and Disassembly windows
and any window that will slow the debug experience, its better that it uses the MVVM way, of notifying them, or they are watching lists from the debug data, and not to hold the debugger till they finish their displaying of the items.
while i don’t mean to interfer in your work, it might be an easy change, plus when these windows run on their own thread, they will be faster.
3. “To diagnose this potential issue, you may need to disable “Just My Code”, as when it is enabled the first chance exception messages do not appear for exceptions occurring in “external code” but the notification overhead is still present”
Maybe a warning inside the “Error list”, informing of the number of the internal exceptions and how much time they took, will give good info for the developer, and a link to how to show them and information on how much they effect the debug experience.
4. “By default IntelliTrace collects select interesting events that you can use to understand what happened in your code after the code execution is long gone and is not on the stack anymore.”
maybe making the IntelliTrace, use the MVVM pattern to be just a watcher not a holder will not hinder the debug experience when its shown, plus when these windows run on their own thread, they will be faster.
5. the overhead of all of the above, can be calculated by the debugger, as it is an internal info, and given as warning in the “Error list”, that has the timing of each long time, with a link to a document to check and fix these issues.
6. “Alternately, disable “Enable property evaluation and other implicit function calls” under Debug -> Options.”
maybe its nice if there is a button in the watch window, that enables/disables the evaluating.
the following connect issue has been made: