Debug vs Release - Why should I use one over the other

[Captain_Jack]

Hi All,

I've always understood that when preparing software for final release and delivery that it should be done using the Release configuration. That's the way all other companies deliver their software, so it just made intuitive sense to me. However, I've recently come across a project that developed and released all of their software modules using the Debug build configuration, and the rationale that I was given was that it makes debugging easier when troubleshooting problems after release. Now we're planning to leverage this software for a new project, and I'm not sure I am willing to support this rationale. Beyond the reason of "because I said so!", there are several reasons why I think this is not a good idea:

1. It's slower to execute Debug Code; although for what we're using it for (drivers and Utilities mostly) this is negligible.

2. There's a potential for issues to occur due to the debug code causing errors or being out of date.

3. There could be differences between the debug and release configurations (not the least of which is the use of the _CVI_DEBUG_ macro to include additional debug code).

4. Also if I recall correctly, in order to debug properly, the source code needs to be available; and this to me is a big fat giant no-no for a production environment.

So beyond the reasons I cited above, and assuming that they are all valid, can anyone provide additional reasons for or against this practice? Any comments would be extremely helpful!Thanks!

-Jack

[RobertoBozzolo]

Hello Jack,

what you say and the items you point out are true and reasonable, with the exception of item #4: the code must absolutely be available in order to debug the application, but not necessarily on the production machine. I mean, you can enable remote debugging of the application, leaving the production machine as is and remotely connecting to it on TCP as described in this white paper.

Nevertheless, at the end of debug process the application should be compiled as release executable and deployed to the production machine for the good reasons you already listed.

[ebalci]

Hi Jack,

The only reason I am tempted to use debug version binary is that it is tested much more than the Release version.
Switching to a Release build is not something you can do at the very end of the project work.

Debug and Release versions have small but important differences. A code working perfectly in debug can fail very badly after built in release mode. Even the faster execution becomes a problem, because your code might have been making use of that delay and a faster execution might ruin the timings.

So make sure you know all differences between debug and release and program carefully and try your final build for a good amount of time.

[Johannes_T · Accepted solution]

Hello Jack,

It's indeed surprising that the company decided to ship builds in debug configuration.

Here are a few more other reasons why delivering debug builds isn't a good practice:

1. Debug builds are slower due to the lack of optimizations.
1. The compiler tends to optimize code in release builds, to make it faster and perform better on specific platforms (it may also slighlty obfuscate code).
2. Unnecessary instructions or data are removed in release builds.
2. Less memory is used by the source code at runtime in release builds.
3. Debug builds may contain debug information stored within the executable/binary itself. This debug information represents stores data about source code, variable names and others. This not only makes the code run slower, but it also exposes internal information (this may probably even reveal proprietary information to your users).
4. Debug builds usually initialize variables and data with 0. This means that programmatic errors will be generally hidden by this.
5. Debug builds are usually (far) larger than release builds and slower.

There are other alternatives to debugging shipped binaries and perform diagnostics on them:

1. Logs: The shipped application can output logs in special folders/files or the Windows Event Log. You can also ask your clients to enable special logging facilities in your application, if the problem can be reproduced consistently, and provide the log outputs to you, for further analysis.
2. Crash dumps can be analyzed using map files even for release builds. The crash address generally refers to a location near a function entry point, that you can trace back from your map files. When you build your binaries in release configuration, the compiler can also generate the map files that you need.

Also, as ebalci mentioned, you should make sure you test your release build thoroughly, before shipping.

Regards,

- Johannes

[Captain_Jack]

Thanks for the feedback!

[SteveD123]

One point that I do not see mentioned up thread is the fact that the default debug build imposes range checking in a lot of places. This slows down loops where you are iterating within an intricate structure with a couple of levels of indirection. Run a release build and things go MUCH faster!

[gdargaud]

If you learn to swim with floaties, why would you take them off when you want to swim across the Channel ?