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 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:
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
DEBUGandTRACEconstants impact any code enclosed in conditional directives, for example: (Substitute DEBUG for TRACE as desired)It also impacts any calls made to methods marked with the Conditional attribute such as
Debug.WriteandTrace.Write: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
DEBUGconstant 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:
Debug info
The
pdb-onlysetting 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 thenonesetting in that the assembly is not impacted, however if you use thepdb-onlysetting (over thenonesetting) 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.