views:

498

answers:

7

Hi,

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 development 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...

A: 

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.

driis
No, I have already deleted all watches to make sure this is not the problem.
Adrian Grigore
+4  A: 

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).

CodeSavvyGeek
+1 last time I experienced slow stepping in visual studio this was the cause
Wim Coenen
Sounds great, but where exactly can I find this option? I haven't seen it anywhere in my roject settings.
Adrian Grigore
I believe it is under the debugging group, but I'm at home and can't check. Also, this option may not be available in Visual C# Express.
CodeSavvyGeek
I'm on Visual Studio Team System, but there is no Debugging group in ASP.NET Web Project settings. Perhaps you mean Tools -> Options -> Debugging -> Just-In-Time -> Native? I've just tried disabling that though and id did not seem to have any effect.
Adrian Grigore
This option is available for Windows Forms and Class library projects and is found under **Project > Properties > Debug > Enable Debuggers > Enable unmanaged code debugging**. This does not appear to be available for web projects, at least not under project properties.
CodeSavvyGeek
+11  A: 

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"
JaredPar
Aaahhhh... So much better now. Thanks a lot, Jared! :)
Adrian Grigore
In Visual Studio 2010 the call stack window seems to only be rebuilt when it is actually visible. An alternative to disabling implicit ToString calls is to right-click on the call stack window and untick 'Display Parameter Values'.
Phil Devaney
@Phil, this was a performance change we made just before Beta2.
JaredPar
@Jared: Thank you!! My problem was actually caused by a DebuggerDisplayAttribute on one of my classes being overly intensive. I moved the logic into the ToString() method and it was much faster. Nice to know it was the property value calculation that was slowing things WAY down. Thanks!!
Doug
+1  A: 

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

Noel Kennedy
+1  A: 

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.

Michael Petrotta
A: 

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.