Watch out: DebugView (OutputDebugString) & Performance

For developer level tracing the tracing classes held within the System.Diagnostics namespace are often used along with the Windows Sysinternals DebugView tool. Tracing events are written to OutputDebugString via the DefaultTraceListener trace listener. 

 

This listener writes output to OutputDebugString (which DebugView can monitor), and a managed debugger (if one is attached). In addition the DefaultTraceListener trace listener is responsible for popping up and dealing with the managed assert message box. You can disable the "default" DefaultTraceListener in your application’s config file as required.

 

This approach to tracing works extremely well and is something I use myself a lot, but you should be aware of the associated performance overhead. DebugView effectively acts as a debugger and hooks the OUTPUT_DEBUG_STRING_EVENT event, as a result your application (a BizTalk process perhaps) will experience a performance impact as the application threads will be suspended whilst the debug information is output, effectively serializing your application. Therefore if you have many Orchestrations in-flight (or multiple threads if your not using BizTalk) they will all be side-affected if DebugView is started and performance will therefore be affected. 

 

It's worth noting that if the DebugView tool is not started (and therefore there are no subscribers to the information) the performance impact is negligible and shouldn't in my experience be something to worry about, therefore do not be afraid to output information that you feel will be useful.

 

Either way you should ensure that your tracing code is implemented such that it can be disabled to reduce the performance overhead, typically you will need the ability to enable it at run-time. When carrying out performance testing you will most likely want to disable tracing, although gaining an understanding of the overhead is also valuable.

 

In my view the performance hit associated with software tracing is outweighed by the ability to diagnose run-time issues in a non-intrusive manner. Most Microsoft products, including BizTalk Server, rely heavily on software tracing which the product group leverage to diagnose customer issues off-line. Just be aware that running DebugView during performance testing or on a live server is very likely to significantly impact performance! I'm not saying not to use it, Please Do! It makes everyone's life easier but just be aware of the performance impact when your running those tests and in live.

Roll on the mighty ETW TraceListener planned for Visual Studio “Orcas”, kernel model ultra-fast tracing from managed code! ETW has been available for a while but has been pretty hard to leverage from managed code. It’s worth nothing that BizTalk itself uses ETW heavily to provide extremely rich internal “developer level” tracing which we can use to diagnose problems at customer sites.

 

Thanks to Jon Fancey for highlighting this during the review stage of the book, he experienced a solution being seriously impacted when DebugView was left running on a live server, and to Matt Ellis (BCL) for adding some detail around the DefaultTraceListener.

Comments

• Anonymous
  April 27, 2007
  We are using this heavily at the moment and in fact we are guilty of using it on production. However we are integrating the use of the Enterprise framework so that we have fine grained control the amount and type and application area we wish to output. I have combined this with a custom trace listener that improves on the standard database listener to log output to a single SQL server table. I'm thinking we may be able to integrate ETW here, or is it worth waiting for Enterprise Framework 3.0. I haven't seen anything about ETW in 3.0, maybe i could create an ETW implementation. Is it worth the effort or is this premature optimisation.