Debugger slows down in C++.NET

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We are a software firm developing in C++ and we recently made the step from
Microsoft Visual Studio 6 to Microsoft Visual Studio .NET 2003. We are really
excited about the quality of the compiler; however there seem to be some
issues with the debugger or the combination of our code with the debugger
that makes debugging very slow and inconvenient.
Since our efficiency in software development seriously decreased, we are
looking for possible solutions for these issues.

Let me first describe our current situation. We have a large code base (the
total size of source code + dll’s + PDB information is more than 6.5 GB of
which the main part debugging information). In the debugger we notice two
main problems:
* The first one is the slowness when stepping through the code (which can be
mainly solved by clearing the visible watch windows, eliminating breakpoints,
etc.). * The second problem is that browsing through objects in the watch
window is very, very slow and is only possible up to a certain level. At each
level the time necessary to go to the next level increases exponentially (for
example the first levels don’t give any problem, but at the 10th level the
CPU load becomes 100% for 30 seconds). The reason that we need to navigate to
such a depth, is that we are using class hierarchies with quite a number of
interfaces, both for our objects and our smart pointers.

We’ve already searched the Internet for related problems and possible
solutions, which lead us to:
· Try to limit the number of breakpoints in general or more specifically the
number of unresolved breakpoints (the following KB is related to this
problem: http://support.microsoft.com/default.aspx?scid=kb;en-us;331684 )
· Disable the anti-virus software
· Debug in native mode
· Try uninstalling IIS (we don’t have it on our development machines)
Of these none really solved our problem.
 
"=?Utf-8?B?UGlldCBWYW4gVmxpZXJiZXJnaGU=?=" <Piet Van
(e-mail address removed)> wrote in
Let me first describe our current situation. We have a large
code base (the total size of source code + dlls + PDB
information is more than 6.5 GB of which the main part debugging
information). In the debugger we notice two main problems:
* The first one is the slowness when stepping through the code
(which can be mainly solved by clearing the visible watch
windows, eliminating breakpoints, etc.). * The second problem is
that browsing through objects in the watch window is very, very
slow and is only possible up to a certain level. At each level
the time necessary to go to the next level increases
exponentially
Click to expand...

We need to investigate this more to know the root cause of your
problem. Can you drop me an email at: tarekm at microsoft dot com
? I'd like to directly engage with your company in finding the
cause of this problem since it is not something that we already
know about.

Thanks,
 
Piet said:
We are a software firm developing in C++ and we recently made the step
from Microsoft Visual Studio 6 to Microsoft Visual Studio .NET 2003.
We are really excited about the quality of the compiler; however
there seem to be some issues with the debugger or the combination of
our code with the debugger that makes debugging very slow and
inconvenient.
Since our efficiency in software development seriously decreased, we
are looking for possible solutions for these issues.

Let me first describe our current situation. We have a large code base
(the total size of source code + dll’s + PDB information is more than
6.5 GB of which the main part debugging information). In the debugger
we notice two main problems:
* The first one is the slowness when stepping through the code (which
can be mainly solved by clearing the visible watch windows,
eliminating breakpoints, etc.). * The second problem is that browsing
through objects in the watch window is very, very slow and is only
possible up to a certain level. At each level the time necessary to go
to the next level increases exponentially (for example the first
levels don’t give any problem, but at the 10th level the CPU load
becomes 100% for 30 seconds). The reason that we need to navigate to
such a depth, is that we are using class hierarchies with quite a
number of interfaces, both for our objects and our smart pointers.
Click to expand...

My experiences are exactly the same, except that my codebase is much,
much smaller. I have also had to face numerous situations where the
debugger just froze up when the application got into trouble (which is
exactly the sort of situation you want a debugger for).

Unfortunately, I don't think this behaviour is due to unusual
circumstances in your (or my) environment. This is just the way the
wretched thing works, an early beta version at best. I suspect that the
multi-language debugging capability and the extra MSIL level are
responsible for the pathetic performance.

In some respects the .NET debugger is a step back behind the debugger I
used for developing Windows 3.1 applications in 1991.

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the thermal post part of my e-mail address
with "kapsch" and the top level domain part with "net".
 
My experiences are exactly the same, except that my codebase is
much, much smaller. I have also had to face numerous situations
where the debugger just froze up when the application got into
trouble (which is exactly the sort of situation you want a
debugger for).
Click to expand...

The slow-down is related to the use of "interop / mixed"
debugging. The interop debugger is a lot slower than the native
debugger in VS2002/2003. If you're not using managed code, then
switching the debugger type to "native" should eliminate most of
the stability and performance issues.

For those developing managed code, we made the "interop / mixed"
debugging story a lot more stable and significantly faster in
VS2005.

Thanks,
 
Tarek said:
The slow-down is related to the use of "interop / mixed"
debugging. The interop debugger is a lot slower than the native
debugger in VS2002/2003. If you're not using managed code, then
switching the debugger type to "native" should eliminate most of
the stability and performance issues.
Click to expand...

As I suspected. Unfortunately, I do use managed code. After all, the
future standard Windows API is going to be managed, isn't it?
For those developing managed code, we made the "interop / mixed"
debugging story a lot more stable and significantly faster in
VS2005.
Click to expand...

This is good news indeed.

A minor (but still annoying) debugger issue: I recently tried to observe
the value of an int parameter in a member function like this:

void X::x (int i) { /*...*/ }

I knew the value must be 20, and the disassembly/register windows
confirmed it was 20, but the watch window stubbornly displayed:

i {__int3}

Is this a known bug?

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the thermal post part of my e-mail address
with "kapsch" and the top level domain part with "net".
 
A minor (but still annoying) debugger issue: I recently tried to
observe the value of an int parameter in a member function like this:

void X::x (int i) { /*...*/ }

I knew the value must be 20, and the disassembly/register windows
confirmed it was 20, but the watch window stubbornly displayed:

i {__int3}

Is this a known bug?
Click to expand...

No, this is not a known bug. I couldn't try to reproduce this with a
simple console applicaiton that has the pattern you described. Can you
reproduce this on a new simple project? If not, can you try to trim the
scenario down to some code that reproduces this same problem?

Thanks,
 
Tarek said:
No, this is not a known bug. I couldn't try to reproduce this with a
simple console applicaiton that has the pattern you described. Can you
reproduce this on a new simple project? If not, can you try to trim
the scenario down to some code that reproduces this same problem?
Click to expand...

I am sorry, but this defect surfaced when debugging a non-trivial
application (> 130 source files). It could easily take me days trying to
reduce the project to the minimum size required to reproduce the error.
We have tight schedules here and no budget to charge such an amount of
work against.

Thank you for your attention.

--
Gerhard Menzl

#dogma int main ()

Humans may reply by replacing the thermal post part of my e-mail address
with "kapsch" and the top level domain part with "net".
 
I am sorry, but this defect surfaced when debugging a
non-trivial application (> 130 source files). It could easily
take me days trying to reduce the project to the minimum size
required to reproduce the error. We have tight schedules here
and no budget to charge such an amount of work against.
Click to expand...

It will be great to let us know whenever you are able to reproduce
this problem with some code that you can share with us. We'd love to
investigate it and get it fixed.

Thanks,
 
Back
Top