• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 255
  • Last Modified:

Why is Visual Studio 2005 debugging so slowly? How can I make it faster?

I have imported a project from Visual Studio .Net 2003, consisting only of native (unmanaged) C++ code. Debugging was very fast in that IDE, and I didn't even notice a delay when stepping over lines. Now, in MSVC 2005, each stepping over takes between 1 and 2 seconds :(

Why is that? Is there anyway to improve the MSVC 2005 debugger speed? I've already configured the project debugger type to Native Only, and I tried to change a lot of debugging options, all without success.

1 Solution
What processor and memory do you have? I found that VS 2005 is very slow on old computers like Pentium III and when RAM is less than 512 MB.
Create new project and test debugging in it - does it happen there or it happens only in one specific project?
e_tadeuAuthor Commented:

I have an Athlon MP 2400+ (Dual Core) with 2GB of RAM!
I created a new project, a very simple one, and the debug is fast there...

The problem is with my older project, but note that this is a big project... it involves python, and it is actually loading 85 modules (.dll's) when debugging. Maybe there is too much symbols??

But I repeat, in MSVC .Net 2003 the debugging was very fast even on this project.
e_tadeuAuthor Commented:
Note: I disabled JIT debugging and Edit&Continue -- same thing.
[Webinar] Cloud and Mobile-First Strategy

Maybe you’ve fully adopted the cloud since the beginning. Or maybe you started with on-prem resources but are pursuing a “cloud and mobile first” strategy. Getting to that end state has its challenges. Discover how to build out a 100% cloud and mobile IT strategy in this webinar.

One suggestion relates to breakpoints

I suppose you have already done a complete clean and rebuild, but just to be sure, I thought I'd mention it.

If the problem is related to too many symbols (that is a heck of a lot of DLLs) you could isolate that problem by turing off debug symbols on all but a few main modules (where you will be debugging) and rebuilding the project.

A google groups search turned up references to problems when debugging when using DirectX and and severla people had unresolved sluggishmess when debugging Web Services.
Hi e_tadeu,

I have done this (with much smaller projects) and not noticed any slowdown. However, I did notice while looking through the settings it had 'interpreted' into the VS2005 form that many were set to 'unintuitive' values.

You may benefit from climbing completely through, in detail, the settings of the projects. If you see something unintended, change it to something better.

For the PAQ database:
Was the problem related to having too many sysmbols?  Did removing the symbols from seldom-used modules make the debugger run faster?  Or was it one of my other suggestions?

-- Dan

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now