So I had to fire up my XP laptop today because my new Rode
Podcaster microphone (which is otherwise is totally awesome) won’t start on Vista
despite getting a usbaudio.sys hotfix from MS Support (which was a suprisingly painless
Anyway – cleaning out my old harddrive I found this picture:
This is a picture of the BAM portal. What I was doing was using BAM to give
me some rough performance metrics between two version of an orchestration. In
the “XmlDocument” version of the orchestration I was reading in a 9MB Xml file into
BizTalk. In the orchestration I was passing the document to a .NET component
as “XmlDocument” and reading the whole document. This is the typical example
code you’ll find for reading BizTalk messages from .NET code.
In the “XmlReader” version of the orchestration – I was passing the message as XLANGMessage.
This is the underlying datatype that the Orchestration compiler uses to represent
a message. Only when you pass it to a .NET component as XmlDocument do they
actually convert it to an XmlDocument (even if your message type on your orchestration
is System.Xml.XmlDocument btw). Inside of the method my code looked something
public static XmlDocument
at the data
XmlDocument ret = new XmlDocument();
XmlReader reader = (XmlReader)old.RetrieveAs(typeof(XmlReader));
new message from old
object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
By calling RetrieveAs and passing typeof(XmlReader) I avoid loading the BizTalk message
into a DOM – and can read the message using standard XmlReader techniques.
As you can see from the BAM metrics (which is not an absolutely high performance timing
mechanism – but in this case should be close enough) the XmlDocument version took
about 3xs as long as the XmlReader version. So rule of thumb – if you care about
performance – use XmlReader with XLANGMessage – not XmlDocument for your .NET methods
from an Orchestration.
Unfortunately the XLANGs compiler won’t allow us to return XmlReader as the return
value – so for constructing we are still stuck with the DOM.