1

I have a large bit of code that takes about 5 minutes to run in debug mode of Visual Studio, and about 10 seconds to run in release mode.

This becomes an enormous issue when I have to debug code at the end of the program, where I have to wait far too long just for the program to hit the breakpoint.

I gave serialization a shot, and used boost::serialize to serialize all the variables before the debug code, but it turns out that deserializing all those variables still takes a minute or two.

So what gives? I'm aware that many optimizations and inline stuff is disabled when running code in debug mode, but it strikes me as very peculiar that it takes almost 2 orders of magnitude longer to run the code in debug mode. Are there any hacks or something programmers use to bypass this wait time? I know there's lots of programs out there much more computationally intensive than mine, but I highly doubt that they would wait 5 minutes just for their debug code to hit a breakpoint.

user1262907
  • 11
  • 1
  • 1
    I have seen similar increases in processing time when I put a breakpoint with a condition inside a loop ( image processing ). The debugger then has to evalute the conditional expression in the breakpoint(s) very loop and can become a significant load. Maybe you have something similar. – Dampsquid Mar 11 '12 at 22:31
  • I agree with dampsquid. Memory watchpoints are another big slowdown. Try running without any breakpoints or watchpoints -- how fast is it? – TonyK Mar 11 '12 at 22:46
  • the time it takes between running in debug with no breakpoints versus running in debug with breakpoints only has a difference of about half a second, which doesn't really mean much when execution time is 5+ minutes. – user1262907 Mar 11 '12 at 22:48
  • You know, you don't need a debug build to debug. You can (usually) use a release build with optimizations turned off. – David Schwartz Mar 11 '12 at 22:49
  • You might want to see if turning off iterator debugging has an effect: http://msdn.microsoft.com/en-us/library/aa985939.aspx Remember that your entire project (including libraries) must be built with the same setting or things may not work. See http://stackoverflow.com/a/6104239/12711 for a bit more detail and http://channel9.msdn.com/Shows/Going+Deep/C9-Lectures-Stephan-T-Lavavej-Advanced-STL-3-of-n for information about `_ITERATOR_DEBUG_LEVEL` which may be relevant as well. – Michael Burr Mar 11 '12 at 23:02
  • Are you sure there isn't any additional slow code of yours that gets compiled and executed in debug builds only? Anything under #if/#ifdef? – Alexey Frunze Mar 12 '12 at 08:11

3 Answers3

2

I have a large bit of code that takes about 5 minutes to run in debug mode of Visual Studio, and about 10 seconds to run in release mode.

That's normal.

So what gives? I'm aware that many optimizations and inline stuff is disabled when running code in debug mode,

That isn't all. In addition to that msvc insert MANY sanity checks, especially when stl containers are involved. For example, it will warn you about incompatible iterators, broken ordering comparator in std::map, and many other similar issues. I think it also detects memory corruption to some extent, and buffer overruns, out of range access for std::vector, etc. This can be useful, but overhead is massive. Throw a certain profiler on top of that and your 10 seconds can as well take 30 minutes to finish. And this will also be normal.

Are there any hacks or something programmers use to bypass this wait time?

Aside from using it instead of #1 excuse...
You could build debug version of your code on mingw - it doesn't insert (this kind of) sanity checks.
You could also investigate source STL libraries and see which macros enables all those features. It is quite possible that it can be disabled. It is also quite possible that said macros is documented somewhere on msdn.
You could try to find alternative STL implementation for the debug mode. YOu could also build release mode with debug info and debug it instead.

SigTerm
  • 26,089
  • 6
  • 66
  • 115
0

OP here, so I was messing around with release builds running without the debugger attached, and found that with VS2010 ultimate (may also be for express too), when a program crashes it gives you a prompt asking if you want to debug or close the program (however before this it asks you if you want to abort, retry, or ignore; choose ignore). Clicking debug and selecting the current open solution in visual studio will load up the code and pretend the entire crash occurred while the program was being debugged.

This essentially means that if you put intentional glitches in your code where you would want a breakpoint, you can run the code in fast release mode without the debugger attached, and start debugging after the program crashes. For the purpose of forcing a crash I created an empty vector and had it try to access an element of the empty vector.

However this method has a major setback, being that it's one-time use. After the program crashes and you start debugging it, you cannot do anything more than view the watchlist and other variables, which means no other breakpoints can be set since you're technically not running a debug-enabled process.

Sure, it's a pretty huge setback, but that doesn't mean the method wouldn't have its uses.

user1262907
  • 11
  • 1
0

Depends on what you want to debug. If you're ready to tolerate some strange behavior, you can usually customize what you want to debug. Try turning on optimization, using release mode libraries (keeping debug info enabled).

dbrank0
  • 9,026
  • 2
  • 37
  • 55