I suggest you ...

Improve Visual Studio Call Stack walking performance

This suggestion is migrated to Developer Community. Please use below link to view the current status.
https://developercommunity.visualstudio.com/content/idea/351371/improve-visual-studio-call-stack-walking-performan.html
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

103 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdminVisual Studio Team (Product Team, Microsoft Visual Studio) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    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.

    Thanks,
    Kaycee Anderson
    Visual Studio

    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

    Andrew Hall,
    Program Manager, Visual Studio Debugger

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      Signed in as (Sign out)
      Submitting...
      • Mark Douglas commented  ·   ·  Flag as inappropriate

        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.

      • Floele commented  ·   ·  Flag as inappropriate

        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.

      • reader commented  ·   ·  Flag as inappropriate

        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
        code editor
        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.

        http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/7173872-make-debugging-faster-with-visual-studio

      Feedback and Knowledge Base