"Roshawn Dawson" <ud****@bellsouth.net> wrote in message news:%2****************@tk2msftngp13.phx.gbl...
This might be a stupid question, but which offers better performance when processing xml?
What sort of processing are you trying to do?
Is it the XmlDocument,
XmlDocument is easiest and most flexible to do processing
where you want to modify something. It's not as fast as the
alternatives execution-wise, because it always involves the
reading of the entire XML file before you can do anything.
From a standpoint of how much of your time you'll spend,
though, it's often faster to write the code to use XmlDocument
then it is to write code for many of the alternatives. For small
files it may be the best choice; spend the development time
you save looking at other places in your application to improve
performance.
XPathDocument,
XPathDocument is a good solution if you are going to read
with XPath expressions. If you just want to read, there are
faster alternatives. It doesn't support modifications, so if
your processing involves modifying something, it's not even
applicable.
using an XSLT file?
If you know XSLT well, then XSLT is very flexible in the
sorts of manipulations you can make. It's good for data-
driven apps (change the XSLT instead of redeploying the
app). However, it always works through one of the other
solutions (commonly XPathDocument or XmlReader), so
it (arguably) can't be faster than they are. In theory, a
compiled XSLT stylesheet (.NET 2.0) could be optimized
to be as fast as a handcrafted XmlReader/Writer, but that
technology is probably several more years away.
You left out the fastest XML processing technique: Xml-
Readers. The simplest modifications may be as easy to
code as an XmlDocument, but complex manipulations
often involve greater investment in developing complex
XmlReaders (either consuming an XmlReader, or extend-
ing an XmlReader). Processing that only reads, and that
doesn't require XPath, can often be fastest when coded
as an XmlReader consumer.
Derek Harmon
