Is it possible to switch from release- to debug-mode ...

[greve]

... during execution of a program? Background: A thermodynamical simulation which yields unexpected results after less than 1min in release mode. If I start that program in debug-mode it takes more than 20mins to get to that point. The system I'm using is VS2013Pro.

Thanks for any responses in advance.
Thomas

[GCDEF]

No it's not. It's unusual that it's that much slower though. Do you have conditional breakpoints set?

You can debug release builds. Just turn on the debugger settings in the release build and debug that. Perhaps it will run faster. On the other hand, 20 minutes isn't all that long.

[OReubens]

You can debug a release build, but you won't have debug information.

You can build a special form of release build with debug information, but due to compiler optimisations this may not allow you fine enough stepping through the code (and inspection of variables) to do what you want.

you can build a release build without optimisations and with debug information, and see if you can still get the error there.



Debug builds can be significantly slower. a 20x slowdown is high but not abnormal.
You could try to speed things up by disabling assertions and verification checks, but it wouldn't be the first time this is actually the cause of the problem.
Some code that is done only in a debug build as part of an assert, but that should be done always.

Alternative ways would be to build in debugging features into the release builds so you can inspect variables and slow down/halt execution etc.
At the simplest level, this would just be some logging to log the most vital information that seems to be going wrong, and then keep fine tuning and logging more detailed info as you home into the problem.

[razzle]

A thermodynamical simulation which yields unexpected results after less than 1min in release mode. If I start that program in debug-mode it takes more than 20mins to get to that point.

I would modify my simulation program so it can be stopped and restarted again from a certain point. This means you need to be able to save the simulation state on file after a certain number of iterations and then reload and restart again from that state at a later time.

If your simulation uses a random number generator it can pose a problem because not all generators can be restarted at a certain point in the random sequence but must always be started from the beginning. You can overcome this by using the same seed and then "dry-run" the generator up to the point in the sequence you want it. In addition to the random generator state there are other data you need to save and reload of course but that's usually less of a problem.

With this modification you can run the simulation for a minute in release mode, stop and save the state. Then load the state in debug mode and continue.

It's maybe a lot of work for just this one time but it would increase the value and usefulness of your simulation program for the future.

---

A more quick fix solution would be to start several (but not too many) incarnations of Visual Studio. You then organise things so you always have several simulations tugging away on their 30 minutes in the background, while you at the same time are debugging a ripe simulation in the foreground.

[superbonzo]

... or supposing the slowdown is due to asserts and the like

if you don't want to touch your production code and you are using a versioning system that allows fast branching (like git), you can profile your debug build and then just create one or more "bug hunting" branches ( that will never merge, of course ) where you can freely and selectively prune "heavy" asserts until you get to an acceptable timing ( to some extent, you can also do this by playing with the NDEBUG-lile macros, but this is dangerous of course ).

BTW, note that even if it's a very good thing (IMO) to protect all functions preconditions with asserts, these should not alter their performance characteristics too much ( like their time/space big-O ) ...

[STLDude]

It is possible that you hit this Checked Iterators, which can really slow down stl containers.