What are the differences between a debug and a release build in C#? How do they affect performance?

(See the article Mysteries of The Net Framework)

Also what about Managed C++. I seemed to remember that the Managed C++ compiler does some additional optimizations about C#. Has anyone actually benchmarked a realistic example?

(personnaly I find Managed C++ the worst of both worlds, but I think that Andrew has written some, and seemed to quite enjoy it!)

Back to your question, does having a debugger attached count? What about a profiler how can that impact? 

And then there's the "Optimize code" option in the build properties - by default this is enabled on Release but not Debug, but that can be changed. (It can have some interesting effects on debugging, though!)

---

Robert Chipperfield
Developer
Red Gate Software Ltd

In Visual Studio, you can choose whether or not to run with debugging (from the Debug menu) independently of whether you're doing a Debug or Release build. The first of those options (run with/without debugging) seems to have more of an impact than whether it's in Debug or Release build mode.

 

That's an interesting observation Steve. 'Cause I have found in native programs (well C++ really) it's quite the reverse. Mainly because the compiler and linker can make extensive optimizations especially the linker if you are "templatetastic". However it does mean that debuging release/heavily optimized binary code really quite challanging.

 

Feel the energy in this post! ;-)

Debug builds embed additional symbolic information in generated executionals/libraries. As well, the code is not optimized: it's larger and slower. In addition to the executionals/libraries/etc. .pdb files are also created that contain source file information such as file names and line numbers. This tracking information makes it possible for the debugger to match up a chain of MSIL with its machine code counterpart, and to track where local variables and function arguments are stored - stepping through is now possible. On the other hand, when in release mode the compiler performs all optimizations in order make the fastest, smallest, most efficient code possible. However, it's not immediately accessible for debugging.

Essentially, debug code is optimized for debugging, while release code is, cue the applause, optimized for performance. Therefore, always deploy (after testing) only release code. Moreover, .pdb files contain information you likely won't want available to end users to see.

It is possible to still allow for debugging production systems by attaching a debugger to the running process by creating the necessary .pdb files: go to project properties -> build -> set the configuration to release -> click advanced -> set Debug Info to pdb-only. Whereas full info for release builds impacts size, performance and code quality, pdb-only does not.

One thing I noticed is that they both have PDB libraries, and if I run an app that was compiled as Release on another machine along with the PDB, the other machine throws an exception outlining line numbers and file paths that are valid on the other machine. Without the PDB, the release app will only show method names in the stack trace without line numbers or file references.

Here is the gist of what I see different between the two build versions:

Debug:

- Allows you to use Debug class (Debug.WriteLine messages)

- Generates addtional information (complete symbolic debug information) to assist in debugging.

- Symbols allow you to break into code and observe heap/stack.

- Runtime behavior of application is exposed allowing you to rearrange memory / next instruction while process is broken into

- Includes #if DEBUG sections of code

- Ignores #if RELEASE sections of code

Release

- Debug methods are disabled (Trace is still available)

- Runtime behavior is not exposed

- Optimized binaries for code execution on targeted platform

- Includes #if RELEASE sections of code

- Ignores #if DEBUG sections of code

- Smaller executable file size

- Faster execution

Build release is optimised, smaller footprint and faster execution as you might expect?

I would like to add one more thing to Lewis's observation.

In a release build methods are inlined, unless you add NoInlining Attribute to the method.

The release builds are optimized for better garbage collection, debug builds tend to let the objects "linger". If you are spinning up many (YMMV) you can consume more resources on the system with a debug build versus a release build.

Actually, I consider this a "trick" question. "Debug" and "Release" are merely two named configurations automatically created by Visual Studio. You can change any and all of the setting associated with any build configuration.

Since I can turn on optimizations in "Debug" and turn them off in "Release", or any other changes I desire, to make any statements merely knowing the names of the build configurations are "Debug" and "Release" is meaningless.

Because of this my firmhas established a practice (going back at least as far as VC++ 4.0) of not using (ie deleting) the default configurations. Instead we have a set of specifically named configurations, as well as a set of "scripts" that validate all of the settings in each named configuration conform to our standards. Our typical configurations include:

"Quick" use for iterative beuild while developing
"Development" a complete build with basic testing as part of the build process
"Check-In" a fairly comprhensive build that must be warning free bfore the SCC system will allow a check in"
"Production" a full build that also includes archiving, proper signing with production keys, etc.

 

 

---

TheCPUWizard is a trademark of Dynamic Concepts Development Corp. Please visit us at www.dynconcepts.com

Not worth me writing a full answer as most things are covered in earlier posts, but inlining is definitely worth reading up on and understanding as the JIT compiler is basically rewriting code as it sees best - its a very useful feature but is often unexpected.

e.g.

given a class containing

private int _count = 6;
public int Count{get{ return _count;}}

and a method accessing it

int count = obj.Count;

after inlining, it may end up behaving more like

int count = obj._count;

I think the question is about default Debug and Release Configuration of VS.
So, I just boxing my thinking to that.
I use Debug.Asset a lot.
Under Debug mode, this will help me to find the bug inside my code, so my code will be solid.
And under Release mode, they are all gone, return performance back for my application.