In Visual Studio 2010, if you go to a project’s properties and go to the Build Tab, there is a checkbox for “Define TRACE Constant.” Which is the equivalent of doing a #define TRACE.
All of the methods of System.Diagnostics.Trace have a [Conditional("TRACE")] around them.
My question is why would you ever turn this off? I mean, if you don’t have any trace listeners defined, then it isn’t as if you’re going to fill up a log or something. It just feels weird to me. If you are going through the effort to put in calls to Trace, why would you want to not control it through the App/Web.config, but instead control it via a compiler switch, which rules out the possibility of turning it back on without a recompile.
Am I missing something? Surely, it can’t be THAT bad for performance, right?
Presumably this checkbox is equivalent to the
/define:TRACEcompiler option. You might want to turn this option off for a release build either because you don’t want end users to see the trace output for some reason (e.g. security), or to improve performance. Of course, the performance increase will depend on how much work is being done when it’s on, but the Conditional attribute will cause the compiler to completely remove the function call (including any string formatting, etc.) from the generated IL, so it could make a significant difference.