Just how much slower should debug mode in VS be?

[Stuart_M_]

Hey folks

I have a model that is normally executed via BAT file, taking about 15 seconds to complete the simulation. When I execute the exact same model application in debug mode from within Visual Studio 2005 (using IVF v11) the same simulation takes 100 seconds.

I expect there to be some delay in the execution time in debug mode because there must be an awful lot going on for debuggers to do all they do, and the model execution itself is conducted from within VS rather than independently (please correct any misconceptions I may have!). However, I have little experience with this so am not sure what is considered a "normal" slow-down in simulation time.

In case any of this makes a difference, the program is a complex model that numerically solves equations for surface water hydrodynamics. So there are plenty of files being opened and read and data written to output, which it seems to be me would probably further contribute to slowing down the execution in debug mode.

Just thought I'd try and get a feel for whether I can move on or should be suspicious of just how slow it's running in debug mode.

Thanks!

[Steven_L_Intel1]

Does this application ever deallocate memory? If so, you're running into a Microsoft "feature" where lots of additional checks are made on deallocation when running under the debugger.

I assume that you are running the same EXE and not comparing a debug build with a release build.

[bmchenry]

the factor of 10 slowdown seems a bit excessive.
1st have you tried to run the codefrom Visual Studio with Debug->Start without Debugging?
How is that speed compared to Debug->Start?

Do you have any conditional breakpoint/tests in the debug code? (where you place a conditional breakpoint can seriously degrade performance).
Do you have enough memory headroom for the program to run in debug mode?

Occasionally I find after many invocations of debug mode the loading of the program/symbols/etc at start of Debug can slow to a crawl (while doing walk throughs, etc.)
To speed back up I simply exit Visual Studio and then start it back up (takes 10 seconds).
Then debug mode once again runs at a respectable pace.

[Stuart_M_]

Steve -

I was actually comparing a release build and a debug build. Unchanged code, but definitely different builds; another reason why I expected there to be differences in execution time. I just don't know what differences to expect. I have now run it from the .bat using the debug build .exe and it takes about 100s, so about what it did to executein debug mode from within VS. Again, compared with about 15s for the release build executed from the .bat.

Regarding memory deallocation,I am pretty unfamiliar with this code butI searched the source code and found no instances of the DEALLOCATE statement. Are there any other statements associated with deallocation I should consider?

bmchenry -

I just tried running it as Debug -> Start without debugging and after about 100s (so possibly at the end of the simulation) I got a "Debug Assertion Failed!" message. Not sure what that implies...

In the current version I have no breakpoints at all. Regarding memory, though the model is big, this particular application is small with a domain of about 100 cells only. Consequently, I don't see memory being an issue, though I should add that I am running this within a version of Windows hosted by Parallels on my quad-core Mac. Parallels has 1gig allocated out of the total 4gigs of RAM, and currently has over 3GB of hard memory available. The process of monitoring memory usage is very new to me - how would I check the state of my memory during the execution (Windows Task Manager?), and what in particular am I looking for?

Thanks gents!

[Steven_L_Intel1]

If performance is about the same with "Start without debugging", then the deallocates are not the issue. It could be that optimization really REALLY helps your program.

The debug assertion failure may or may not be important. What else did it say?

[Andrew_Smith]

My application speeds up about 5 times in release build compared to full debug due to optimization and vectorization (SSE). I suspect less wellwritten numerical code could see bigger improvements since it gives the optimizer more oportunities to re-order and elminate.
Andy

[Stuart_M_]

Quoting - Steve Lionel (Intel)

If performance is about the same with "Start without debugging", then the deallocates are not the issue. It could be that optimization really REALLY helps your program.

The debug assertion failure may or may not be important. What else did it say?

Hey Steve - this is my "Debug Assertion Failed!" error message

Any reason why I would only get this when using "Start without debugging"?

[Stuart_M_]

The numerical solution technique is based on an alternating-direction implicit method in which the horizontal velocity components in the x- and y-directions are computed at alternating half time-steps.

I have no idea what sort of optimization is possible with this compiler, nor how optimization is achieved, so whether his is useful information or not I don't know...

[Steven_L_Intel1]

No idea on that one. By default, a debug configuration links with the debug MSVC libraries which do a lot of consistency checking at program exit. I don't know what that specific complaint is about and I suggest you ignore it for now.