Improving debugger stepping performance in Visual Studio 2005

2005-09-01T00:56:00Z

Stepping in Visual Studio 2005 is affected by numerous factors.

1. Debugger windows you have open e.g. the callstack window requires us to walk the stacks every time you complete a step, Auto/Locals and watch window require us to evaluate all expressions in those windows after you complete the step.

2. Visualizers /Autoexpanders provided by the engines

Autoexp.dat for native code.

Visual 2005 improves on autoexp.dat but adding support for STL types and also doing an "auto" expand on existing types. Some of the STL displays can be expensive (more on this later)

Debugger display attributes for managed code.

Debugger displays can translate to execution of a function in the debuggee context, this is inherently very expensive for the debugger because the callstacks have to be refreshed once the function call is executed (more on this later)

3. Interop debugging, stepping and callstack walking is more involved.

4. Remote debugging, requests have to be made on the remote box where debug-gee resides.

We worked very hard on improving the stepping performance in Visual Studio 2005. However, its very likely that there are users scenarios we missed.

There are things that can improve stepping performance if this turns out to be an issue for you.

Close the Auto and Locals Window
Right click on the callstack window and turn off display of Parameter Types, Parameter Values and Parameter Names (these can actually be key off item #2 )
Close the callstack window (note that even with the callstack window closed, the debugger will request some callstack frames from the engine)

RPC Debugging - Do you use it?

2004-08-03T21:23:00Z

The Visual Studio C++ Debugger since VC6.0 have had this feature called RPC debugging. It was turned off by default and is present somewhere in Tools | Options [|Debugger]

What does it do? Well, COM has provided hooks for debuggers that enable them to step into and out of COM calls that go across threads when the apartment rules require it (e.g STA calling into a MTA component).

With RPC debugging turned on, when you do a step in at such a call site, you will automatically land at the callee on a different thread (assuming the COM rules necessitated a cross thread marshaled call), you can also step back out of the callee and back into the caller.

Caveats:

1. You have to be an administrator for this to work. COM requires this.

2. If you have a proxy DLL then we require that it's compiled with source level debugging information off (or compile with no debug info), This is because if you do have source and step in, we assume you want to stop in the proxy code since it has source line information.

3. AFAIK, windbg does not support this.

In Whidbey we extended this feature to support some mixed debugging debugging scenarios, meaning you can do cross thread stepping from a managed to native call site across different threads and vice versa.

This posting is provided "AS IS" with no warranties, and confers no rights.

rajra's WebLog

Improving debugger stepping performance in Visual Studio 2005

RPC Debugging - Do you use it?