More from the “we fix VS.NET” department – in todays episode, we’ll take a look at the VS.NET debugger and make it faster. Or at least fast enough so you don’t want to smash your computer waiting for it…
The steps are ordered by ease of discovering the problem, i.e. a log of my journey. If you aim for more speed, start at the back and work your way up instead.
Step 1: Disable all watches and breakpoints you don’t desperately need.
They affect the overall speed of your debugger. Even worse, in a mixed mode environment, some breakpoints seem to accumulate – especially if you’ve got files with the same name in several plug-ins. So just running the debugger multiple times without cleaning your breakpoints might very well accumulate cruft. So go forth and clean it out.
Step 2: Disable “Evaluate Expressions”
Why? Because Visual Studio re-evaluates all expressions in your watch window every single time you step, set a breakpoint, or do anything else in your debugger. And it’s not exactly fast when evaluating those little buggers…
Step 3: Set the debugger type.
Unless you want to debug managed code, make sure you set MSVC to use a “native only” debugger. Go to the projects settings, Debugging. There’s a field called “Debugger Type”.
Set it to “Native Only” to debug native code, or “Managed only” if you have to do managed code. If you absolutely have to debug both, pick mixed. Under no circumstances leave it set to “Auto” – that slows down debugging tremendously. It seems to take about a second every single time you step to re-evaluate if this is managed or unmanaged code – and it doesn’t always get it right.
Step 4: Fix the annoying startup delay
If you run VS.NET’s debugger a lot, you’ll find that it has this annoying 10-second pause where nothing happens. At least it does for mixed-mode executables. It took me a long time to find it, but a post in Google Groups finally steered me in the right direction. Amazingly enough, a Microsoft library (diasymreader.dll) reference an MS-internal build machine as the location for the debug symbols. So unless you have a machine \cpvsbuild on your network, VS.NET will try to find that machine, wait for a message from the miracle that is MS networking, and after 10 seconds give up and continue.
The solution: Add the line
127.0.0.1 cpvsbuild
to your lmhosts file in Windows\System32\Drivers\etc
Or, if you’re brutal like I am, open diasymreader.dll in your hexeditor of choice, and replace \cpvsbuild with a local directory that doesn’t exist. I.e. c:\fooledya
Happy debugging!
Step 3 is the worlds best tip. You deserve mountains of gold for that.
Thank you.
Thank you thank you thank you. You really helped me out with the step 3 tip!
Glad I could help
Thanks for step 3 and 4. Best tips ever.
We added in 6 managed files and development became unbelievably painful due to those slow downs.
Thank you!
Hey, are those fixes for Io? My pleasure!