views:

938

answers:

8

What's the difference between Debug and Release?

+3  A: 

If you go through project compile options and compare them, you'd see what are the differences.

Assuming the question is about native/C++ code (it's not entirely clear from the phrasing):

Basically, in Debug all code generation optimizations are off. Some libraries (e.g. STL) default to stricter error checking (e.g. debug iterators). More debugging information is generated (e.g. for "Edit and Continue"). More things are generated in code to catch errors (local variable values set to uninitialized pattern, debug heap is used).

NeARAZ
He's talking about .NET...
Vilx-
@Vilx: when I aswered, there was no .net tag yet, only visualstudio. So I assumed it's C++.
NeARAZ
+1  A: 

Mostly, debug includes a lot of extra information useful when debugging. In release mode, this is all cut and traded for performance.

Rik
A: 

It's probably worth mentioning the very obvious, that build flags allow for different logic which should be used just to change logging and "console" messaging, but can be abused and dramatically change not just the low-levels but the actual business logic.

annakata
+1  A: 

Also note that when using MFC for example, debug projects link against non-redistributable DLL versions like MFC90D.DLL while release builds link against the redistributable versions like MFC90.DLL. This is probably similar with other frameworks.

Therefore you will probably not be able to run debug-build applications on non-development machines.

mxp
very true. Ran afoul of this once while at a client. Works on My Machine (TM).
Matt Jacobsen
+1  A: 

The obvious difference you can see is the size of the binary. Debug build produces a larger binary than Release build.

When compiling in Debug, the symbol table is added to the compiled object of the code file which allows for debugging programs to tap into these binaries and asses the values of objects and variables.

Another observable difference is that, in Release mode, the binary would simply crash on a fatal error while in Debug mode, if you start debugging the application in Visual Studio, you can check the call stack which tells you the exact location of the erroneous statement.

fasih.ahmed
+6  A: 

The most important thing is that in Debug mode there are no optimizations, while in Release mode there are optimizations. This is important because the compiler is very advanced and can do some pretty tricky low-level improving of your code. As a result some lines of your code might get left without any instructions at all, or some might get all mixed up. Step-by-step debugging would be impossible. Also, local variables are often optimized in mysterious ways, so Watches and QuickWatches often don't work because the variable is "optimized away". And there are multitudes of other optimizations too. Try debugging optimized .NET code sometime and you'll see.

Another key difference is that because of this the default Release settings don't bother with generating extensive debug symbol information. That's the .PDB file you might have noticed and it allows the debugger to figure out which assembly instructions corresspond to which line of code, etc.

Vilx-
"As a result some lines of your code might get left without any instructions at all, or some might get all mixed up".YUP, fell foul of this using Stack frames to get the name of the current method/property - and a lot of the properties got inlined in release...
kpollock
"The most important thing is that in Debug mode there are no optimizations" - that's arguable. the most important thing is that there is debug information which allows you to debug. although that can exist in release as well.
shoosh
+4  A: 
MadKeithV
A: 

Also, apparently, Debug mode creates a lot of extra threads to help with debugging. These remain active throughout the life of the process, regardless of whether you attach a debugger or not. See my related question here.

Matt Jacobsen