odd performance question - xml parsing

[Mark]

Hi...

We've been doing some basic performance testing comparing asp, asp.net,
mono, and php. One of the basic tests is on simply parsing an xml document
and streaming the result back to the client.

I never would have thought of it, but someone in our group had heard that
using XmlDocument.Loa d (Server.MapPath (file));
was slower than actually creating the stream, the XmlTextReader, and passing
the reader to the XmlDocument.Loa d();.

I've tried it, and darn if he wasn't right.

System.Xml.XmlD ocument DOMObj = new System.Xml.XmlD ocument();
System.IO.Strea mReader stream = new System.IO.Strea mReader
(Server.MapPath ("file.xml") );
System.Xml.XmlT extReader reader = new System.Xml.XmlT extReader(strea m);
reader.Whitespa ceHandling = System.Xml.Whit espaceHandling. None;
DOMObj.Load(rea der);

was 5% faster than

System.Xml.XmlD ocument DOMObj = new System.Xml.XmlD ocument();
System.Xml.XmlT extReader reader = new
System.Xml.XmlT extReader(Serve r.MapPath ("file.xml") );
reader.Whitespa ceHandling = System.Xml.Whit espaceHandling. None;
DOMObj.Load(rea der);

which was 20% faster than
System.Xml.XmlD ocument DOMObj = new System.Xml.XmlD ocument();
DOMObj.Preserve Whitespace = true;
DOMObj.Load(Ser ver.MapPath("fi le.xml"));

I can't think of any reason why it's so much faster to manually create your
own stream and XmlTextReader rather than letting XmlDocument figure out the
fastest way to process the document.

Any ideas?

Thanks
_mark

[Bruce Barker]

doc.load(filena me) - creates a validating xml reader, which is why its so
slow

new XmlTextReader(f ilename) - expects a uri, not a filename. if no protocol
is specified, then its converted to a file based uri (file://filename), then
opened as a uri resource. this transalation requires serveral directory
lookups.

new XmlTextReader(r eader) - just read the stream of bytes from the reader.
if you pick one optimized for file opening and reading, its fastest.

-- bruce (sqlwork.com)
"Mark" <mm******@nospa m.nospam> wrote in message
news:34******** *************** ***********@mic rosoft.com...

Hi...

We've been doing some basic performance testing comparing asp, asp.net,
mono, and php. One of the basic tests is on simply parsing an xml
document
and streaming the result back to the client.

I never would have thought of it, but someone in our group had heard that
using XmlDocument.Loa d (Server.MapPath (file));
was slower than actually creating the stream, the XmlTextReader, and
passing
the reader to the XmlDocument.Loa d();.

I've tried it, and darn if he wasn't right.

System.Xml.XmlD ocument DOMObj = new System.Xml.XmlD ocument();
System.IO.Strea mReader stream = new System.IO.Strea mReader
(Server.MapPath ("file.xml") );
System.Xml.XmlT extReader reader = new System.Xml.XmlT extReader(strea m);
reader.Whitespa ceHandling = System.Xml.Whit espaceHandling. None;
DOMObj.Load(rea der);

was 5% faster than

System.Xml.XmlD ocument DOMObj = new System.Xml.XmlD ocument();
System.Xml.XmlT extReader reader = new
System.Xml.XmlT extReader(Serve r.MapPath ("file.xml") );
reader.Whitespa ceHandling = System.Xml.Whit espaceHandling. None;
DOMObj.Load(rea der);

which was 20% faster than
System.Xml.XmlD ocument DOMObj = new System.Xml.XmlD ocument();
DOMObj.Preserve Whitespace = true;
DOMObj.Load(Ser ver.MapPath("fi le.xml"));

I can't think of any reason why it's so much faster to manually create
your
own stream and XmlTextReader rather than letting XmlDocument figure out
the
fastest way to process the document.

Any ideas?

Thanks
_mark

[Mark]

Thanks for the great answer, Bruce...

-Mark