0

While debugging inside VS2010, programs naturally run a lot slower than otherwise.

However, lately my programs run at an indescribably slow rate if I'm updating the values of a ListBox. (Other controls may also be affected, I'm not sure... but ListBox is a sure thing).

Operations which happen in tiny fractions of a second outside the debugger, like adding 100 elements to a ListBox, can take as long as 3 to 5 minutes inside VS.

Clearly, this isn't normal behaviour.

I'm not sure when this started, but it hasn't been happening always. It started happening a couple of months ago. Maybe when I installed the service pack? I'm not sure.

When I look at the processes, msvsmon.exe is chewing through CPU.

Any ideas if there is some option somewhere that I may have changed which causes this? I'm trying to debug something with a ListBox containing 8,000 elements and It's just completely impossible.

Windows 7 x64, 4GB RAM, VS2010-SP1

Ozzah
  • 10,631
  • 16
  • 77
  • 116
  • 1
    Q: What language: C#? VB.Net? Other? Q: What target: Winforms? WPF? Other? Q: How does the app behave when it's *not* run from the MSVS debugger? Q: How does the app behave when you compile for "release" (instead of "debug") and run it outside MSVS? Q: How are you populating the listbox? – paulsm4 May 24 '12 at 03:37
  • What is your computer doing when your application is running slowly? – John Saunders May 24 '12 at 03:39
  • 2
    Look in the Output window. Is it filled with "First chance exception" messages? Don't swallow exceptions, fix them. – Hans Passant May 24 '12 at 03:44
  • @paulsm4 C# 4.0, Winforms. Outside the debugger the program runs smoothly. Instant ListBox population. I haven't compiled this program in release. I call `BeginUpdate()`, then add all the elements I want, then I call `EndUpdate()`. – Ozzah May 24 '12 at 03:49
  • @HansPassant Yes, I can see a lot of `System.InvalidCastException`s in the output window. – Ozzah May 24 '12 at 03:51
  • Science experiment: per the link below, please delete all breakpoints, and see if anything improves. – paulsm4 May 24 '12 at 03:52
  • @paulsm4 I have no breakpoints in my program at all! – Ozzah May 24 '12 at 03:52
  • @HansPassant I have looked at my `populate()` function and I have no try/catch anywhere. I'm not sure where they are coming from - is there any way I can find it? – Ozzah May 24 '12 at 03:53

3 Answers3

3

Yes, I can see a lot of System.InvalidCastExceptions in the output window

That's what causes the slow-down, the debugger does a lot of work when it processes an exception. Especially the remote debugger you are using now, required because your project's platform target is AnyCPU, adding the notification message to the Output window isn't cheap.

You can't ignore this problem, it is not just a debugger artifact. Debug + Exceptions, tick the Thrown box for CLR Exceptions. The debugger will now stop when the exception is thrown. You'll need to fix that code.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Ahh, I found the problem. In my `Equals` overload, I try to cast the object as my entity and catch `InvalidCastException` and return false. I've since re-written it using the `as` word and check if the object is null and then return false. – Ozzah May 24 '12 at 03:59
  • 2
    You didn't really write try/catch in an Equals method, did you?? Tsk, tsk. – Hans Passant May 24 '12 at 04:00
1

The problem might be the way VS2010 handles breakpoints. Look at this link:

Two interesting notes:

  • Searching for symbols is often very slow at the start of debug, particularly if you have one of the remote symbol options configured, and have not set 'ignores' on the various DLLs which will not have symbols on MS servers.

...

  • Yes, msvsmon.exe will be used when you debug a 64-bit program. Since Visual Studio is completely 32-bit, the remote debugger is needed to bridge the divide. ... Working mightily to find and load the .pdb files would be likely. Or accidentally having the mixed-mode debugging option turned on so the debugger is also seeing all unmanaged DLL loads and finding symbols for them. These are just guesses of course.
Community
  • 1
  • 1
paulsm4
  • 114,292
  • 17
  • 138
  • 190
0

One more cause of slownes - conditional breakpoints as the condition need to be evaluated on each hit to the breakpoint. Having a breakpoint that have "false" for condition inside a long loop will slow debugging significantly.

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179