Performance Differences Between Debug and Release Builds

Debug vs. Release performance

Partially true. In debug mode, the compiler emits debug symbols for all variables and compiles the code as is. In release mode, some optimizations are included:

unused variables do not get compiled at all
some loop variables are taken out of the loop by the compiler if they are proven to be invariants
code written under #debug directive is not included, etc.

The rest is up to the JIT.

Full list of optimizations here courtesy of Eric Lippert.

Performance differences between debug and release builds

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.

Release build vs. Debug build performance

A good choice of algorithm definitely will make a big difference in speed of a debug build, but debug builds will never be as fast. It's because the optimizer schedules registers completely differently, trying to make code run fast, while the debug compiler tries to preserve values of temporary variables so you can read them from the debugger.

Since you probably have a lot more variables than CPU registers, this means the debug compiler will emit instructions to copy those values to RAM. While in a release build, if the value isn't used again, the optimizer will just throw it away.

Performance difference Debug vs Release

I found various sources that there should be little to no performance difference with the debug and release version of Visual Studio.

This is quite probably incorrect, or misinterpreted information ^{... or, apparently, information about a different language}. In case of misinterpretation, the original statement may have been that debug symbol information has no effect on performance, which would be correct.

Regardless, extra debug operations enabled by _DEBUG (Visual studio specific) or disabled by NDEBUG (standard macro that controls assertions) do have overhead. How significant overhead is depends on what the program does. If it spends most of the time waiting for harddrive or network, then probably not very significant. If it does a lot of operations on containers, then overhead is probably more significant.

Even more significant performance difference will come from lack of optimisations, that are enabled in Release build, and not in Debug build.

Drastic performance differences: debug vs release

As you use std::vector, It will help to disable iterator debugging.

MSDN shows how to do it.

In simple terms, make this #define before you include any STL headers:

#define _HAS_ITERATOR_DEBUGGING 0

In my experience, this gives a major boost in performance of Debug builds, although of course you do lose some Debugging functionality.

What is the difference between Debug Mode and Release Mode in Visual Studio 2010?

In Debug Mode your .exe has debug information inside of it (source code, variable names and other similar stuff like that).

In Release Mode your .exe lack of debug information makes it smaller and probably performs better due to its smaller footprint.

Is there any (performance) difference between Debug and Release?

I figured it out, I allowed unsafe code in one of my dependencies build.
I am still wondering why it is behaving like that, but I'll have to dig this a bit more.

Thanks for all your help!

Debug vs Release in optimization of .net (concerns when distributing to users)

There is no security issue that I can think of. There is most certainly a performance issue, the Debug build of your assemblies contains an attribute (DebuggableAttribute) that will always prevent the jitter optimizer from optimizing the code. This can make a great deal of difference on the perf of the running program. Optimizations performed by the jitter are documented in this answer.

You could have a problem with memory consumption. The garbage collector will operate differently, keeping local variables alive until the end of the method body. This is a corner case and such a problem should have been diagnosed while testing the app, assuming you used realistic data.

Specific to VB.NET, shipping the Debug build can very easily cause your program to crash with an OutOfMemoryException when it is run on your user's machine without a debugger attached. It fails due to a leak on WeakReferences, used by Edit+Continue to keep track of classes that have an event handler with the WithEvents keyword.

If you don't have a need for the perf enhancements produced by the jitter optimizer and don't ship VB.NET assemblies then there isn't much to worry about.