Performance differences between debug and release builds

Question

I must admit, that usually I haven\'t bothered switching between the Debug and Release configurations in my program, and I have usually opted to go for the

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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: 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).

Answer 5

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 fewer errors are shown (higher tolerance), hence a switch should work fine.

Answer 6

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. Loops with small bodies are improved by repeating the code up to 4 times in the body and looping less. Reduces the branch cost and improves the processor's super-scalar execution options.

• 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. The optimizer of a C compiler will spend a lot more time on finding opportunities to hoist. It is however an expensive optimization due to the required data flow analysis and the jitter can't afford the time so only hoists obvious cases. Forcing .NET programmers to write better source code and hoist themselves.

• Common sub-expression elimination. x = y + 4; z = y + 4; becomes z = x; Pretty common in statements like dest[ix+1] = src[ix+1]; written for readability without introducing a helper variable. No need to compromise readability.

• 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 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.