Very slow debugging

I have the 2.0 framework on one computer and haven't tested it anywhere else, but I'm experiencing very slow debugging. I have a Windows Form app with about 60 classes/forms. Sometimes after making a few character change in code it takes 30 seconds before I can continue in the editor. Opening a form with a lot of controls on it can take almost a minute. The hard-drive runs almost continuously during these "wait" times. The computer is a 3.2GH P4 with has 2GB RAM and 700GB (fast) disk. I know that the 2.0 editor does a lot more work than the 1.1 editor did, but the wasted time during coding is very PAINFUL - anyone else having these issues Any ideas why

TIA




Answer this question

Very slow debugging

  • jens_essen

    The issue appears to be the MS Debugging Assistant which does the on-the-fly CLR code modifications which add debugging power but can kill performance. Check out the MSDEV 2005 product feedback entry that explains the issue:.

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx feedbackid=e976ea2a-ba1e-4537-9493-46af9429a81e

    The quickest workaround for me was to set COMPLUS_MDA to 0 in the env vars - I set it and restarted Dev Studio and Walla! it was working as fast as it used to in 2003! You can also control this setting from the registry, and you can also do it per application using a config file (probably the best way). You'll find the details on how to disable the MDA here:

    http://msdn2.microsoft.com/en-us/library/d21c150d(en-US,VS.80).aspx

    I hope this spares some of you out there debugging agony like it did for me - I was having too many coffee cups after hitting F5 :)

    As you can see from the product feedback correspondence, MS was aware of this issue since Beta.


  • ralex

    I am experience very slow debugging on .NET 2.0 as well, dozens of times slower than the same program .NET 1.1. I get thw slow performance in VS.NET 2005 as well as CLR Debugger 2.0. Turning off all debugging options doesn't make a difference.

    Is this an inherent problem .NET 2.0 or is it a configuration issue With the current performance I'm actually sticking asserts in the middle of my code to start debugging only when I have to!


  • Marc H. Young

    I seem to have a clue about the reason: when I run my Debug build with F5 (using the debugger), I can see all object members fields (e.g. properties) in the Watch window. When I run it with Ctrl+F5 (no debugger) to run fast (it runs at least 10x faster) and then use an Assert to break into the debugger using JIT in the middle of execution, then the debugger says my code is optimized and displays only data fields that are accessible directly (no properties, etc.).

    Now, I tried turning off the evaluate properties feature (as well as all other debugger options) and this makes no difference in performance. The point is not whether the properties can be evaluated, but that debugger says 'code is optimized', even when running under Debug build, if you use Ctrl+F5.

    My guess is that there are some basic optimizations (perhaps some of them are done on-the-fly, when you choose to execute the code) that make the code run reasonably fast and are always used by default (even in Debug builds where aggressive optimizations are off). However, the debugger automatically turns these optimizations off, and that's the reason for the major slow down.

    I'm fairly confident this is part of the reason, because I noticed that the level of slow down caused by the debugger is highly dependant on the type of code I am running. Certain pieces of code take much greater performance hits than others (tight loops with delegate use are used heavily in my code). This selective performance hit hints that there is indeed an absence of basic optimizations, which unfortunately are necessary for some code to run reasonably fast.

    Note that the new WinDbg CLR debugger runs fast like under .NET 1.1 (but it's much harder to use than MSDEV). The CLR debugger provided with the .NET 2.0 SDK runs just as slow as MSDEV 2005 (must be the same code).

    Can someone please help us:

    What do you think is the best way to get Microsoft's attention about this issue, and have someone from the MSDEV team give us some insight, and suggest a workaround And if the problem has no workaround, then MS should give us the option to run the debugger without disabling optimizations. How can we approach them about this

    Thanks!

    Avner.


  • Yatharth Gupta

    I have the same problem. My system will become unuseable while trying to debug a C# application. Any help with this would be helpful because VS2005 is totally unusable now for debugging
  • Ogedei

    I have speed up all my debugging unchecking the option "Allow Property evaluation in variables windows", actually this option presens all the content of all your current properties, just a waste of CPU cycles.

    Hope this helps



  • Very slow debugging