So we are pretty happy with our program. It's fast and stable in Debug mode and so far that's the version live with customers. We now desire that free boost we get from a release build.

I have now compiled the project 开发者_StackOverflow中文版for Release with Code Optimization : On. I have TRACE constant : Off. Advanced -> output -> debug info -> None.

Besides efficient coding pracsises and system architecture etc, what are the optimal Visual Studio settings for adjusting the C# application for max performance?

As far as I know the JITter optimizes the IL compilation by default in Release builds. The Code Optimization (: On) concerns the compiler and how it deals with inlining etc.

Is that it or is there more? Is turning the TRACE constant off a mistake? (our application mails us with the stack tree if something serious should go wrong, I'm not sure if TRACE is related here)

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.

An approach I've seen used in several programs (Paint.NET and Adobe Acrobat Reader come to mind) is that they use ngen on their managed assemblies upon installing. This provides little runtime boost, but startup times are decreased, as JIT does not have to be used anymore.

This can be used alongside other optimizations that you do.

(Note that you cannot run ngen as a part of your build process, because it takes into account the specifics of the hardware it is currently being run on)

The performance between release and debug is usually hardly noticeable.

Most C# programs spend the vast majority of their time in .net assemblies which are already optimized.

I don't there is much more you can do that through VS that will give you significant enough or noticeable performance gain. You will be better off spending the time running the program through profiler and look at where you can fine tune the code. Spend a bit of time refactoring some of the code in particular relating to IO, db and use parallel/thread and caching when suitable may get you a much better outcome