开发者

Visual Studio 2008 : Step to next line is very slow when debugging managed code

开发者 https://www.devze.com 2022-12-13 08:20 出处:网络
When stepping through my C# code line by line via F10, it takes the debugger over one second to get to the next line.

When stepping through my C# code line by line via F10, it takes the debugger over one second to get to the next line.

I've tried deleting all watches and breakpoints, but that did not make any difference.

Is this normal? It's been like this for quite a long time now, so I can't even remember if this was ever better. My deve开发者_运维知识库lopment computer is a Quad-core machine with no background task activity and plenty of RAM left.

If it's not normal, what else could I try? It's still ok to work with, but a less sluggish user interface would be great...


What's likely happening is you have a variable in the call stack frame which has an expensive .ToString method. In 2008, the data for the call stack window is rebuilt on every step regardless of whether or not the window is actually visible. Part of building this window will call .ToString on the values which appear in the parameter list if they have an overridden .ToString. Try disabling implicit .ToString calls and see if that fixes the problem.

  • Tools -> Options -> Debugger
  • Uncheck the "Enable Implicit .ToString calls"


I have found that if you have the option to debug unmanaged code turned on, the debugger can take a while to step between lines even if you are only debugging managed code. Try turning that option off (Project > Properties > Debug > Enable Debuggers > Enable unmanaged code debugging).


I tried all of the above. Unchecking 'Show Threads In Source' button fixed it.


In my case, disabling "break all processes when one process breaks" (Tools/Options/Debugger) reduced the time to "step over" from 2-3 seconds to a fraction of a second.

I have no idea why this option had such a big effect on doing a single step over. BTW, I suppose that disabling this option might cause trouble if you are using threads that are not independent from each other.


I once experienced slow debugging as I had set up VS to look for pdb files on a network share that didn't exist any more.

Check here : Tools - options - Debugging - Symbols - Symbol file (.pdb) Locations


I've heard of this kind of problem if the "Auto" window is open. Try closing that and see if your performance improves.

If you haven't already, you should probably also install the "Visual Studio 2008 SP1 debugging and breakpoint" patch. Note that this patch goes on top of SP1. The docs for the patch don't specifically address the slowness that you're seeing, but it's a pretty large patch, and you might get lucky.


Turn off the Enable address-level debugging option in Tools > Options > Debugging > General.
It made a huge difference for me.


Do you have a lot of Watch expressions set up ? They will be evaluated after between each step, and if they take time to run, you will notice it as a delay when stepping.


I was experiencing a 10 second delay after stopping C# debugging before being able to start C# debugging again. VS2008 would hang during this time with nothing clickable. There is now a 0 second delay after I disabled the Visual Studio hosting process in Project Properties -> Debug.

0

精彩评论

暂无评论...
验证码 换一张
取 消