Setting up a C# application for max performance build

These are the recommended settings that I would choose for a release build, all of these settings are found on the "Build" tab of the project properties:

• Uncheck "Define DEBUG constant"
• Uncheck "Define TRACE constant"
• Check "Opimize code"
• Under the "Advanced..." dialog set "Debug Info:" to "pdb-only"

You may also wish to consider using ngen to speed up application start time. This process must be done on the end user PC (normally as part of the installation process) however will generally only improve application performance the first time that it is run*. My advice would be to consider using ngen only if you have a specific concern over the cold boot time of your app.

What do these settings actually do?

DEBUG and TRACE constants

The DEBUG and TRACE constants impact any code enclosed in conditional directives, for example: (Substitute DEBUG for TRACE as desired)

#if DEBUG
// Anything here will not appear in the end output unless the DEBUG constant is defined
#endif

It also impacts any calls made to methods marked with the Conditional attribute such as Debug.Write and Trace.Write:

// The following call will not appear in the end output unless the DEBUG constant is defined
Debug.WriteLine("Test");

You can check both of these for yourself by using something like IL Spy.

Note that these constants have no other effect, for example the JITer doesn't behave differently if the DEBUG constant is defined. You will probably find that these have neglible effect in your application unless you make hefty use of conditional directives.

Optimize code

This controls what optimisation both the compiler (cs.exe) and the JIT compiler perform when compiling your code. You are likely to see the bulk of your performance improvements as a result of this setting.

The following question covers what this setting does in more detail:

• Benefits of 'Optimize code' option in Visual Studio build

Debug info

The pdb-only setting tells the compiler to put all debug information in a separate .pdb (program database) file. As far as the end assembly is concerned this is exactly the same as the none setting in that the assembly is not impacted, however if you use the pdb-only setting (over the none setting) symbols are at least available if you wish (you don't have to distribute them if you don't want to). This can be pretty useful for example when debugging crash dumps.

Note that you can't "go back" and re-generate symbols for an existing assembly - once you have a lost the .pdb for an assembly (or chose not to create one in the first place) it is pretty much lost forever! Take care of it (especially for assemblies that you release "to the wild").

The only real difference that you will see here is output assembly size - this may impact loading times and memory footprint, but ultimately this setting probably wont have a particularly noticable effect.

---

(*) assuming that the user exercises most / all of the features of the application the first time they run it - the JITing process is done as a method is called. Read up on JITting / ngen for more detail.