Improve Visual Studio Call Stack walking performance
This suggestion is migrated to Developer Community. Please use below link to view the current status.
Walking the call stack can sometimes be a slower operation when debugging. Do not slow down debug operations such as stepping when walking the call stack takes a long time
Thanks for the feedback, we are currently investigating what performance improvements we could make to give you a faster experience when debugging, particularly when the call stack walking is causing the slowness.
See the following blog posts that offers more details on what settings and windows relate to this, and other tips and tricks for speeding up debugging in general. http://blogs.msdn.com/b/visualstudioalm/archive/2015/03/03/make-debugging-faster-with-visual-studio.aspx
Program Manager, Visual Studio Debugger
Igor Kolomiiets commented
debugging of pure C++ for 32-bit with VS 2015. CLR off. code optimizations off
Mark Douglas commented
Debugging a 32-bit java application that loads native C++ code. Native code loads managed classes that call into C# code.
I debug the application by attaching to the running javaw.exe process.
When I attach and debug 'native' only, everything is responsive - single stepping, entering breakpoints etc. are all fine.
If I attach to the process and also enable Managed debugging, things go really badly. Entering a breakpoint and single stepping take over a minute each! Yes, pressing F10 to step over a simple statement takes over a minute to perform.
The solution is to close the 'Threads' window, but I wish I didn't have to do this.
Type of application: Mixed (C++/WPF/WinForms) x86 application written in C++ and C#, running under a native only debugger. I often have significant wait times for simple tasks like stepping (F10, F11) as long as the call stack window is visible. Often I don't need the call stack though. So it would be indeed very helpful if the window loaded asynchronously at least, but making it somewhat faster in general wouldn't hurt either.
The managed debugger is much faster btw, I don't have any issues with the call stack there.
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.
Calculate/update the callstack asyncronously