views:

304

answers:

8

i must admit, that usually I haven't bothered swithcing between the Debug and Release configurations in my program, and I have usually opted to go for the Debug configuration, even when the programs are actually deployed at the customers place.

As far as I know, the only difference between these configurations if you don't change it manually is that Debug have the DEBUG constant defined, and Release have the Optimize code checked of.

So my questions is actually twofold:

1) Are there much performance differences between these two configurations. Are there any specific type of code that will cause big differences in performance here, or is it actually not that important?

2) Are there any type of code that will run fine under the Debug configuration that might fail under Release configuration, or can you be certain that code that is tested and working fine under the Debug configuration will also work fine under Release configuration.

+7  A: 
  1. Yes, there are many performance differences and these really apply all over your code. Debug does very little performance optimization, and release mode very much;

  2. Only code that relies on the DEBUG constant may perform differently with a release build. Besides that, you should not see any problems.

An example of framework code that depends on the DEBUG constant is the Debug.Assert() method, which has the attribute [Conditional("DEBUG)"] defined. This means that it also depends on the DEBUG constant and this is not included in the release build.

Pieter
This is all true, but could you ever measure a difference? Or notice a difference while using a program? Of course I don't want to encourage anyone to release their software in debug mode, but the question was if there is a huge performance difference and I can't see that.
testalino
Also worth noting is that debug versions correlate to the original source code to a much higher degree than release versions. If you think (however unlikely) that someone might try to reverse-engineer your executables, you don't want to make it easier on them by deploying debug versions.
jwiscarson
@testalino - Well, these days it's difficult. Processors have gotten that fast that the user hardly waits for a process to actually execute code because of a user action, so this is all relative. However, if you're actually doing some lengthy process, yes you will notice. The following code e.g. runs 40% slower under `DEBUG`: `AppDomain.CurrentDomain.GetAssemblies().Sum(p => p.GetTypes().Sum(p1 => p1.GetProperties().Length))`.
Pieter
Also, if you are on `asp.net` and use debug instead of release some scripts might be added on you page, such as: `MicrosoftAjax.debug.js` that has about 7k lines.
BrunoLM
+2  A: 

I would say that 1) largely depends on your implementation. Usually, the difference is not that huge. I did lots of measurements and often I couldn't see a difference. If you use unmanaged code, lots of huge arrays and stuff like that, the performance difference is slightly bigger, but not a different world (like in c++). 2) Usually in release code less errors are shown (higher tolerance), hence a switch should work fine.

testalino
For code that is IO bound, a release build could easily be no faster that debug.
Richard
+1  A: 

In my experience, the worst thing that has come out of Release mode are the obscure "release bugs". Since the IL (intermediate language) is optimized in Release mode, there exists the possibility of bugs that would not have manifested in Debug mode. There are other SO questions covering this problem: http://stackoverflow.com/questions/1762088/common-reasons-for-bugs-in-release-version-not-present-in-debug-mode

This has happened to me once or twice where a simple console app would run perfectly fine in Debug mode, but given the exact same input, would error out in Release mode. These bugs are EXTREMELY difficult to debug (by definition of Release mode, ironically).

Roly
To follow up, here's an article that gives an example of a Release Bug: http://www.codeproject.com/KB/trace/ReleaseBug.aspx
Roly
Bear in mind, however, that these types of bugs (actual bugs in the jitter or optimizing compiler) are quite rare. I suspect the vast majority of release-build bugs are legitimate bugs that a Debug build happens to suppress or make less likely to occur.
Dan Bryant
Still its a problem if the application is tested and approved with the Debug settings, even if it suppress errors, if that causes the release build to fail during deployment.
Øyvind Bråthen
+2  A: 
  • My experience has been that medium sized or larger applications are noticeably more responsive in a Release build. Give it a try with your application and see how it feels.

  • One thing that can bite you with Release builds is that Debug build code can sometimes suppress race conditions and other threading-related bugs. Optimized code can result in instruction reordering and faster execution can exacerbate certain race conditions.

Dan Bryant
+3  A: 

This heavily depends on the nature of your application. If your application is UI-heavy, you probably won't notice any difference since the slowest component connected to a modern computer is the user. If you use some UI animations, you might want to test if you can perceive any noticeable lag when running in DEBUG build.

However, if you have many computation-heavy calculations, then you would notice differences (could be as high as 40% as @Pieter mentioned, though it would depend on the nature of the calculations).

It's basically a design tradeoff. If you're releasing under DEBUG build, then if the users experiences problems, you can get a more meaningful traceback and you can do much more flexible diagnostic. By releasing in DEBUG build, you also avoid the optimizer producing obscure Heisenbugs.

Lie Ryan
Thanks for the link...I didn't know there was a name for those types of bugs. Interesting
Roly
+1 for the Heisenbug reference alone :)
Øyvind Bråthen
A: 

1. Faults: I, never got error with release when my debug works fine, but some lazy initialization will be happens in release, also as I know C# will be handle all initialization, but if you using some unmanaged code within your managed application, if the unmanaged code skip some items initialization in release you will got exception or bad manner, I'd this issue when I'm using some COM object written in C++ and using them in C#.

2. Speed:

Release speed is better than debug, because in debug the code will be generated for each line positioning and related debug settings (debug table) also release removes extra actions (for example not used loops, variables, ...) so the performance of release is better, when your project size going to increase you can see the release performance improvement.

SaeedAlg
+15  A: 

The C# compiler itself doesn't alter the emitted IL a great deal in the Release build. Notable is that it no longer emits the NOP opcodes that allow you to set a breakpoint on a curly brace. The big one is the optimizer that's built into the JIT compiler. I know it makes the following optimizations:

  • Method inlining. A method call is replaced by the injecting the code of the method. This is a big one, it makes property accessors essentially free.

  • CPU register allocation. Local variables and method arguments can stay stored in a CPU register without ever (or less frequently) being stored back to the stack frame. This is a big one, notable for making debugging optimized code so difficult. And giving the volatile keyword a meaning.

  • Array index checking elimination. An important optimization when working with arrays (all .NET collection classes use an array internally). When the JIT compiler can verify that a loop never indexes an array out of bounds then it will eliminate the index check. Big one.

  • Loop unrolling. Short loops (up to 4) with small bodies are eliminated by repeating the code in the loop body. Avoids the branch misprediction penalty.

  • Dead code elimination. A statement like if (false) { /.../ } gets completely eliminated. This can occur due to constant folding and inlining. Other cases is where the JIT compiler can determine that the code has no possible side-effect. This optimization is what makes profiling code so tricky.

  • Code hoisting. Code inside a loop that is not affected by the loop can be moved out of the loop.

  • Common sub-expression elimination. x = y + 4; z = y + 4; becomes z = x;

  • Constant folding. x = 1 + 2; becomes x = 3; This simple example is caught early by the compiler, but happens at JIT time when other optimizations make this possible.

  • Copy propagation. x = a; y = x; becomes y = a; This helps the register allocator make better decisions. It is a big deal in the x86 jitter because it has so few registers to work with. Having it select the right ones is critical to perf.

These are very important optimizations that can make a great deal of difference when, for example, you profile the Debug build of your app and compare it to the Release build. That only really matters though when the code is on your critical path, the 5 to 10% of the code you write that actually affects the perf of your program. The JIT optimizer isn't smart enough to know up front what is critical, it can only apply the "turn it to eleven" dial for all the code.

The effective result of these optimizations on your program's execution time is often affected by code that runs elsewhere. Reading a file, executing a dbase query, etc. Making the work the JIT optimizer does completely invisible. It doesn't mind though :)

The JIT optimizer is pretty reliable code, mostly because it has been put to the test millions of times. It is extremely rare to have problems in the Release build version of your program. It does happen however. Both the x64 and the x86 jitters have had problems with structs. The x86 jitter has trouble with floating point consistency, producing subtly different results when the intermediates of a floating point calculation are kept in a FPU register at 80-bit precision instead of getting truncated when flushed to memory.

Hans Passant
+1: Now that is a comprehensive answer!
Brian Gideon
+1: A very good answer. I appreciate the time you used to write this down.
Øyvind Bråthen
@Brian - thank you very much for keeping this answer alive.
Hans Passant
+1 for great detail and for Spinal Tap reference! :-)
Roly
@Hans: No problem: Great Answer.
Brian Gideon
+2  A: 

You should never release a .NET Debug build into production. It may contain ugly code to support Edit-and-Continue or who knows what else. As far as I know, this happens only in VB not C# (note: the original post is tagged C#), but it should still give reason to pause as to what Microsoft thinks they are allowed to do with a Debug build. In fact, prior to .NET 4.0, VB code leaks memory proportional to the number of instances of objects with events that you construct in support of Edit-and-Continue. (Though this is reported to be fixed per https://connect.microsoft.com/VisualStudio/feedback/details/481671/vb-classes-with-events-are-not-garbage-collected-when-debugging, the generated code looks nasty, creating WeakReference objects and adding them to a static list while holding a lock) I certainly don't want any of this kind of debugging support in a production environment!

binarycoder
I know I shouldn't. My question was simply how much it mattered even if you did ;)
Øyvind Bråthen