Differencebetween Debug and Release in Visual Studio

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

Well, it depends on what language you are using, but in general they are 2 separate configurations, each with its own settings. By default, Debug includes debug information in the compiled files (allowing easy debugging) while Release usually has optimizations enabled.

As far as conditional compilation goes, they each define different symbols that can be checked in your program, but they are language-specific macros.

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.

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

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.

Difference between Debug and Release folders

Just to be clear, the name of the folders in your question are virtually unlimited (not simply limited to debug and release). Right click on your solution and select Configuration Manager and you can add as many configurations as you would like. The name of the configuration is the name of the folder.

As Joshua wrote, usually, people use their debug config to include things like the .pdb file (which includes debugging symbols needed to get line numbers from errors, etc.). Release is normally cleaner. However, you can easily setup folders for x86 vs. x64 vs. any cpu.

If you have a solution with 10 different projects (not uncommon if you work on something of decent size) you might want to build certain projects together and others together. In this case, you should create additional configurations to support this so you can build a group simply by changing your active configuration.

In the end, the folders you mentioned contain whatever you specify in the configuration manager that they should contain.

What is the difference between .pdb files generated from Release and Debug mode?

There is no technical difference like file format or features used.

But since the binary is optimized in release mode, some symbols may be missing (like local variables) or changed (like inlined methods). Thus you need one PDB matching the debug build and another PDB matching the release build.

What you sometimes find is this: companies create public PDBs using PDBCopy. The private information (like private methods) will then be removed. This makes debugging harder but still better than nothing. You can e.g. use this if you publish an API for developers. This public/private thing can be applied to both, debug build or release build.

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.

Is there a difference between Debug and Release Mode in terms of memory allocation while using c++ in VS 2015

This is covered in detail on MSDN, in particular: CRT Debug Heap Details.

what does mean by debug build and release build, difference and uses

Debug build and release build are just names. They don't mean anything.

Depending on your application, you may build it in one, two or more
different ways, using different combinations of compiler and linker
options. Most applications should only be build in a single version:
you test and debug exactly the same program that the clients use. In
some cases, it may be more practical to use two different builds:
overall, client code needs optimization, for performance reasons, but
you don't want optimization when debugging. And then there are cases
where full debugging (i.e. iterator validation, etc.) may result in code
that is too slow even for algorithm debugging, so you'll have a build
with full debugging checks, one with no optimization, but no iterator
debugging, and one with optimization.

Anytime you start on an application, you have to decide what options you
need, and create the corresponding builds. You can call them whatever
you want.

With regards to external libraries (like wxwidgets): all compilers have
some incompatibilities when different options are used. So people who
deliver libraries (other than in source form) have to provide several
different versions, depending on a number of issues:

release vs. debug: the release version will have been compiled with a
set of more or less standard optimization options (and no iterator
debugging); the debug version without optimization, and with iterator
debugging. Whether iterator debugging is present or not is one thing
which typically breaks binary compatibility. The library vendor should
document which options are compatible with each version.
ANSI vs. Unicode: this probably means narrow char vs wide wchar_t
for character data. Use which ever one corresponds to what you use in
your application. (Note that the difference between these two is much
more than just some compiler switches. You often need radically
different code, and handling Unicode correctly in all cases is far from
trivial; an application which truly supports Unicode must be aware of
things like composing characters or bidirectional writing.)
static vs. dynamic: this determines how the library is linked and
loaded. Usually, you'll want static, at least if you count on deploying
your application on other machines than the one you develop it on. But
this also depends on licensing issues: if you need a license for each
machine where the library is deployed, it might make more sense to use
dynamic.

Debug vs. release in .NET

"Debug" and "Release" are just names for predefined project configurations defined by Visual Studio.

To see the differences, look at the Build Tab in Project Properties in Visual Studio.

The differences in VS2005 include:

DEBUG constant defined in Debug configuration
Optimize code enabled in Release configuration

as well as other differences you can see by clicking on the "Advanced" button

But you can:

Change the build settings for Debug and Release configurations in Project Propeties / Build
Create your own custom configurations by right-clicking on the solution in Solution Explorer and selecting Configuration Manager

I think the behaviour of the DEBUG constant is fairly clear (can be referenced in the #if preprocessor directive or in the ConditionalAttribute). But I'm not aware of any comprehensive documentation on exactly what optimizations are enabled - in fact I suspect Microsoft would want to be free to enhance their optimizer without notice