Performance differences between debug and release builds

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

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.

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.

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.

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

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!

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.

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

    **Debug Mode:**
    Developer use debug mode for debugging the web application on live/local server. Debug mode allow developers to break the execution of program using interrupt 3 and step through the code. Debug mode has below features:
   1) Less optimized code
   2) Some additional instructions are added to enable the developer to set a breakpoint on every source code line.
   3) More memory is used by the source code at runtime.
   4) Scripts & images downloaded by webresource.axd are not cached.
   5) It has big size, and runs slower.

    **Release Mode:**
    Developer use release mode for final deployment of source code on live server. Release mode dlls contain optimized code and it is for customers. Release mode has below features:
   1) More optimized code
   2) Some additional instructions are removed and developer can’t set a breakpoint on every source code line.
   3) Less memory is used by the source code at runtime.
   4) Scripts & images downloaded by webresource.axd are cached.
   5) It has small size, and runs fast.

I know that my answer is VERY late and my answer doesn't exactly what you want but, I thought some solid and simple example to play with would be good. Anyway, this piece of code results in a HUGE difference between Debug and Release. The code is written in C++ on Visual Studio 2019. The code is like this:

#include <iostream>

using namespace std;

unsigned long long fibonacci(int n)
{
	return n < 2 ? n : (fibonacci(n - 1) + fibonacci(n - 2));
}

int main()
{
    int x = 47;

    cout << "Calculating..." << endl;
    cout << "fib(" << x << ") = " << fibonacci(x) << endl;
}