Performance difference between a .NET assembly built in debug and release mode?

Question

Some previous developers put some assemblies that were built in debug mode into production. Is it worth recompiling them in release mode and redeploying them? If there's just a 1-2% performance increase, I'd probably just leave them there. On the other hand, a 10-20% increase might change my mind.

Answer 1

In my experience, I saw a 30-40% difference. This was with DotNetZip, a library that does encryption, compression, and a little file i/o. Over 85% of the time was spent in encryption and compression, just moving bytes around.

Answer 2

Another argument against using debug builds in production is because they consume much more memory since debug symbols are required to be loaded.

Answer 3

Generally you will see a benefit because the release version is typically compiled with optimizations using the /optimize compiler option. However, how big the difference will be will depend on your specific assembly - you will need to profile.

Answer 4

I had this same question about a year ago because we were having major performance issues in production. As it was explained to me from MS Premier support the debug build versions include hooks for debugging which can result in about 1 - 10 % increase in memory consumption depending upon what the application does.

If you are not having problems then leave them alone, but if you are having problems with memory consumption then go ahead and recompile / deploy.

Answer 5

I've found that the performance difference increases exponentially with the complexity of the code - a simple application may only see a 5% difference, but I've seen as much as a 50% slowdown on complex applications, especially ones which involve larger data structures like arrays or maps.

There's of course the possibility that debug code could be slightly different as well, depending on how you are set-up - look at assertions for example.

Answer 6

It is worth noting that release code also removes some preprocessor stuff like:

#if DEBUG
...
#endif

It also removes Debug.WriteLine, Debug.Assert, and some other stuff in the System.Diagnostics namespace, which can be useful in testing, but are pointless in well designed code for the release build.

Answer 7

If you look at the IL code generated for Debug and Release builds the differences are generally quite small. Most of the differences lie in additional nop commands at key source points to support Edit and Continue and source line debugging. However when the .NET runtime actually JITs the MSIL the runtime assembly is almost identical. The biggest difference comes when a debugger is attached. That will prevent the JIT from optimizing the actual running code.

Release versions are often much smaller as well because they just don't include as much code. There's can be patches of code surrounded with #if DEBUG statements as well as Conditional attributes that instruct the compiler to omit calls to methods in release mode (Like Debug.WriteLine).

I've found that the Debug.WriteLine and Trace.WriteLine methods, when left in production code and have a significant performance implications even if a debugger is not attached.