Geeks With Blogs
The Unstable Mind of a .Net Developer

On 09/09/09, I blogged on the System.Diagnostics namespace and specifically the TraceSource class.  I wanted to follow up that discussion with just a little more information about using TraceSource in production applications.

One of the things mentioned in my original post is that in order for Trace to function within an application, that application has to be compiled with the TRACE constant.  This will add some overhead to execution as the compiler will not be able to fully optimize the code.  It appears that TraceSource also requires the TRACE constant, though I have yet to find documentation that confirms this.  It then becomes important to decide if the benefits of using TraceSource outweigh any performance degradation.  For discussion purposes, let us assume that the benefits outweigh the detriments.

So, how do you minimize the overhead when using TraceSource?  Even if you use TraceSource, you still want to be prudent with resources.  The answer requires an understanding as to how TraceSource works (simplified for brevity).

  1. The application calls one of the trace methods (TraceEvent, TraceInformation, etc.) on the TraceSource, specifying the source level (Critical, Information, etc.) and trace message
  2. The framework determines whether to publish the trace based upon the source level and the trace level configured on the SourceSwitch associated with the TraceSource.  If the source level is less than or equal to the trace level, the trace is published
  3. Listeners subscribe to these traces and are configured for a specific destination and source level.  If traces are published with a source level less than or equal to the trace level, the listener consumes the trace and writes it to the appropriate destination

As you can see from step 2, the SourceSwitch serves as a gatekeeper (I am the keymaster, are you the gatekeeper?) of sorts.  Traces with a source level higher than the SourceSwitch are not published, reducing overhead.  You can maximize the savings by setting the trace level of the SourceSwitch to Off.  This prevents any traces at all from being published.  If you want only exceptions to be published, set the trace level to Error and so on.

    <switches>
      <clear/>
      <add name="sourceSwitch" value="Off"/>
    </switches>

BTW, adjusting the source level of the listeners (or removing them altogether) would also reduce overhead incurred using TraceSource.  However, the traces will still be published, incurring that overhead, even if there are no listeners to subscribe to the traces.  And, let us not forget the DefaultTraceListener.

Finally, by leveraging this feature, we can now deploy trace enabled applications to production without fear that performance would be seriously degraded.  Furthermore, when the need arises, trace can be turned on by one simple change in the application’s .config file.  And, it is all built in to the .Net framework.  Cool.

Ralph Wheaton
Microsoft Certified Technology Specialist
Microsoft Certified Professional Developer

Posted on Monday, September 14, 2009 9:16 AM System.Diagnostics , VS.Net , TraceSource , TraceEvent | Back to top


Comments on this post: Adventures in System.Diagnostics – The Sequel

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Ralph Wheaton | Powered by: GeeksWithBlogs.net