2

What is the performance hit of using System.Diagnostics.Debug.WriteLine in BizTalk artefacts?, e.g. an orchestration expression shape, a pipeline custom component?

Both when there is something like DbgView capturing the messages, and when nothing is capturing

Or is there a better way to handle debug/trace through the code?

SteveC
  • 15,808
  • 23
  • 102
  • 173

3 Answers3

4

For best performance you should use Microsoft BizTalk CAT Instrumentation framework for tracing and logging. You can find more details on http://blogs.msdn.com/b/appfabriccat/archive/2010/05/11/best-practices-for-instrumenting-high-performance-biztalk-solutions.aspx

Vikas Bhardwaj
  • 1,455
  • 8
  • 10
3

If you compile in release mode, there is no effect because all the System.Diagnostics.WriteLine code is removed by the compiler-- no perf cost, no diagnostic benefits (in production) ref System.Diagnostics.Debug.WriteLine in production code

If you use TraceSource it's a different story, especially if you leave in the default trace listener, which is rather expensive. For production trace, you want something that you can turn on and off, usually via a config file so you only pay the perf cost for the duration of the diagnostic checks you are running on production.

Community
  • 1
  • 1
MatthewMartin
  • 32,326
  • 33
  • 105
  • 164
0

The impact of System.Diagnostics.Debug is no different in BizTalk vs. any other .NET application so all the same rules and considerations apply.

For true Debug purposes, it's not something I would worry about, it's a tax you have to pay. And keep in mind, all Debug calls are removed in Release mode.

Johns-305
  • 10,908
  • 12
  • 21