Start Without Debugging(CTRL F5) 3x slower than Start With Debugging(F5)!

[lostnewmexico]

This one has me at whit's end.

In order for this to make sense, I will have to lay out the "facts" to
get a hypothesis. There is no easy way to explain this.

Environment: VC2005. MFC Application. Native only.

I compile and link the App.

If I hit CTRL-F5....results 700 ms. (does not recompile or relink)
If I double click in debug folder..700 ms. (does not recompile or
relink)
If I hit F5 (Start With Debugging)...result 200 ms. (does not recompile
or relink)

Profiling the code shows that a computationally expensive function
takes 3 times as long if NOT being debugged. Oddly, a function thats
being called from a DLL takes the same amount of time in both
instances. In other words, it is not a uniform slowdown of the App.
So what are some differences between CTRL-F5 and F5?

Working directory for one.

So to make SURE that both are using the same sets of DLLs, I copy all
the DLL's that the debugger loads(shown in output window) into a
temporary directory, and place my app there.

I run the app. Still 700 MS.

What other differences are there between attaching the debugger and NOT
attaching the debugger that could cause this kind of slowdown????

[lostnewmexico]

Additional Detail:

I have found that the culprit is the _DEBUG preprocessor directive.

As I understand it, _DEBUG causes things to be handled differently at
the CRT level...

Is this perhaps a data alignment issue? I don't want to be
distributing debug builds....

lo***********@yahoo.com wrote:

This one has me at whit's end.

In order for this to make sense, I will have to lay out the "facts" to
get a hypothesis. There is no easy way to explain this.

Environment: VC2005. MFC Application. Native only.

I compile and link the App.

If I hit CTRL-F5....results 700 ms. (does not recompile or relink)
If I double click in debug folder..700 ms. (does not recompile or
relink)
If I hit F5 (Start With Debugging)...result 200 ms. (does not recompile
or relink)

Profiling the code shows that a computationally expensive function
takes 3 times as long if NOT being debugged. Oddly, a function thats
being called from a DLL takes the same amount of time in both
instances. In other words, it is not a uniform slowdown of the App.
So what are some differences between CTRL-F5 and F5?

Working directory for one.

So to make SURE that both are using the same sets of DLLs, I copy all
the DLL's that the debugger loads(shown in output window) into a
temporary directory, and place my app there.

I run the app. Still 700 MS.

What other differences are there between attaching the debugger and NOT
attaching the debugger that could cause this kind of slowdown????

[David Wilkinson]

lo***********@yahoo.com wrote:

Additional Detail:

I have found that the culprit is the _DEBUG preprocessor directive.

As I understand it, _DEBUG causes things to be handled differently at
the CRT level...

Is this perhaps a data alignment issue? I don't want to be
distributing debug builds....

lo***********@yahoo.com wrote:

This one has me at whit's end.

In order for this to make sense, I will have to lay out the "facts" to
get a hypothesis. There is no easy way to explain this.

Environment: VC2005. MFC Application. Native only.

I compile and link the App.

If I hit CTRL-F5....results 700 ms. (does not recompile or relink)
If I double click in debug folder..700 ms. (does not recompile or
relink)
If I hit F5 (Start With Debugging)...result 200 ms. (does not recompile
or relink)

Profiling the code shows that a computationally expensive function
takes 3 times as long if NOT being debugged. Oddly, a function thats
being called from a DLL takes the same amount of time in both
instances. In other words, it is not a uniform slowdown of the App.
So what are some differences between CTRL-F5 and F5?

Working directory for one.

So to make SURE that both are using the same sets of DLLs, I copy all
the DLL's that the debugger loads(shown in output window) into a
temporary directory, and place my app there.

I run the app. Still 700 MS.

What other differences are there between attaching the debugger and NOT
attaching the debugger that could cause this kind of slowdown????

lostnewmexico:

I think you are confusing running under the debugger (versus not) with
debug build versus release build.

In debug build, _DEBUG is always defined, regardless of whether you are
running under the debugger.

In release build, _DEBUG is not defined, and you normally do not run
under the debugger (though you can).

I think you are telling us about speeds of the debug build, with and
without the debugger attached. What you say does surprise me, but
ulimately all that matters is the speed of the release build. I would
hope that it would be faster than the debug build (with or without the
debugger).

David Wilkinson

[lostnewmexico]

Thanks for the response David,

I'm not confusing the two...the issues seem to be intertwined.

Check this out:

With _DEBUG defined:

200 MS with or without Debugger attached.

With NDEBUG defined:

200 MS with Debugger attached.
700 MS without Debugger attached.

[lostnewmexico]

Thanks for the response David,

I'm not confusing the two...the issues seem to be intertwined.

Check this out:

With _DEBUG defined:

200 MS with or without Debugger attached.

With NDEBUG defined:

200 MS with Debugger attached.
700 MS without Debugger attached.

[Bruno van Dooren]

> Is this perhaps a data alignment issue? I don't want to be

distributing debug builds....

one thing with debug builds: they are built by default to enable buffer
overload detection and extra runtime checking.
For example, if you corrupt your stack in debug build, you get debugger
output messages saying so. I've seen this a few times.
This implies (at least i think it does) that during your program execution,
there is a lot of stuff going on in the background.

when you are ready to release your application, change the configuration to
release. rebuild, and ship the output of the release configuration.
the release configuration will always be faster than the debug builds.
because it will be optimized, and not do all of the debugging stuff.

--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

[David Wilkinson]

lo***********@yahoo.com wrote:

Thanks for the response David,

I'm not confusing the two...the issues seem to be intertwined.

Check this out:

With _DEBUG defined:

200 MS with or without Debugger attached.

With NDEBUG defined:

200 MS with Debugger attached.
700 MS without Debugger attached.

Well, there is more difference between debug and release builds than
just _DEBUG and NDEBUG. Optimization level, library versions ... Are
you creating a true release build?

David Wilkinson

[lostnewmexico]

David Wilkinson wrote:

lo***********@yahoo.com wrote:

Thanks for the response David,

I'm not confusing the two...the issues seem to be intertwined.

Check this out:

With _DEBUG defined:

200 MS with or without Debugger attached.

With NDEBUG defined:

200 MS with Debugger attached.
700 MS without Debugger attached.

Well, there is more difference between debug and release builds than
just _DEBUG and NDEBUG. Optimization level, library versions ... Are
you creating a true release build?

David Wilkinson

Thats true David, but the only thing I am changing is the _DEBUG to
NDEBUG for this...Essentially, I delted my Release configuration, made
a new Release configuration out of Debug, then flipped things until
this problem reoccured.

The ONLY thing that is different is the _DEBUG to NDEBUG change.

So I guess I need to find out the exact differences between the two.

[Greg]

> Essentially, I delted my Release configuration, made

a new Release configuration out of Debug,

I don't think NDEBUG vs. DEBUG is making the diference. My guess is that you
have some debug build options(s) set in both the release and debug builds. It
could be that the symbol file loads faster or is preloaded when running in
the debugger but is simply unused overhead when not using the debugger.

To really prove it out - try a true release build (e.g. no symbol
generation, optimize for speed, etc.) and then compare that to running under
the debugger vs. outside the debugger.
--
Greg McPherran
www.McPherran.com

[lostnewmexico]

In case this could possibly help someone else, I found the problem.

For some reason, when you divide a float by 0, this takes a lot more
time under release than debug to generate or deal with the quiet NAN's.

I