XmlDocument vs XPathDocument performance

Hi...

I've been trying to improve the performance of our xml handling, so I've
been doing some timing tests lately and ran across something I thought odd -
XPathDocument seems slightly slower than XmlDocument. I've run the tests
several times and have tried to eliminate extraneous variables like disk
access but every time, XPathDocument comes up slower by a few percent.

I'd expected it to be faster since it's a read-only representation. Am I
doing something wrong?

start = Timers.QueryPerformanceCounter();
for (int idx = 0; idx < 50000; idx++)
{
StringReader sr = new StringReader(xmldoc);
doc = new XmlDocument();
doc.Load(sr);
}
start = Timers.SinceMilliSeconds(start);
Console.WriteLine(start);

start = Timers.QueryPerformanceCounter();
for (int idx = 0; idx < 50000; idx++)
{
StringReader sr = new StringReader(xmldoc);
pDoc = new XPathDocument(sr);
}
start = Timers.SinceMilliSeconds(start);
Console.WriteLine(start);

In other tests, XPathDocument seemed to improve
XslCompiledTransform.Transform performance very slightly, but not enough to
justify the switch given that the loading seemed more expensive...

Thanks
Mark

Steven Cheng [MSFT]

Guest

n/a Posts

June 27th, 2008
07:20 PM
#2

Re: XmlDocument vs XPathDocument performance

Hi Mark,

As for the XPathDocument, it has different implementation internally. You
can use reflector to check its constructor. It use an Additional
XPathDocumentBuilder and the loading process is also a bit more complex
than the XmlDocument. I think this is probably due to the specific
implementation required for XPathNaviagtor generation.

For your scenario, if you haven't particular XPath based navigation
requirement, a normal XmlDocument is enough for standard DOM based
read/edit.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
Join Bytes!.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.--------------------

Quote:

Originally Posted by

>From: =?Utf-8?B?TWFyaw==?= <mmodrall@nospam.nospam>
>Subject: XmlDocument vs XPathDocument performance
>Date: Thu, 5 Jun 2008 08:56:03 -0700

Quote:

Originally Posted by

>
>Hi...
>
>I've been trying to improve the performance of our xml handling, so I've
>been doing some timing tests lately and ran across something I thought odd

Quote:

Originally Posted by

>XPathDocument seems slightly slower than XmlDocument. I've run the tests
>several times and have tried to eliminate extraneous variables like disk
>access but every time, XPathDocument comes up slower by a few percent.
>
>I'd expected it to be faster since it's a read-only representation. Am I
>doing something wrong?
>
>start = Timers.QueryPerformanceCounter();
>for (int idx = 0; idx < 50000; idx++)
>{
StringReader sr = new StringReader(xmldoc);
doc = new XmlDocument();
doc.Load(sr);
>}
>start = Timers.SinceMilliSeconds(start);
>Console.WriteLine(start);
>
>start = Timers.QueryPerformanceCounter();
>for (int idx = 0; idx < 50000; idx++)
>{
StringReader sr = new StringReader(xmldoc);
pDoc = new XPathDocument(sr);
>}
>start = Timers.SinceMilliSeconds(start);
>Console.WriteLine(start);
>
>In other tests, XPathDocument seemed to improve
>XslCompiledTransform.Transform performance very slightly, but not enough

Quote:

Originally Posted by

>justify the switch given that the loading seemed more expensive...
>
>Thanks
>Mark
>
>

=?Utf-8?B?TWFyaw==?=

Guest

n/a Posts

June 27th, 2008
07:20 PM
#3

Re: XmlDocument vs XPathDocument performance

Hi Steven...

There are a number of cases, such as applying xsl stylesheets where we don't
require the source to be read/write. I'd assumed that since XPathDocument
wouldn't have to support the write side of things that it might be faster for
read-only type applications. I was surprised to find that if anything it
seemed slightly slower, and that was odd to me.

I can understand given the widespread use that a *lot* of effort went into
optimizing XmlDocument, but I was looking to shave a few cycles going
read-only where I could. I was just surprised that it went the other way.

Thanks
Mark

"Steven Cheng [MSFT]" wrote:

Quote:

Originally Posted by

Hi Mark,
>
As for the XPathDocument, it has different implementation internally. You
can use reflector to check its constructor. It use an Additional
XPathDocumentBuilder and the loading process is also a bit more complex
than the XmlDocument. I think this is probably due to the specific
implementation required for XPathNaviagtor generation.
>
For your scenario, if you haven't particular XPath based navigation
requirement, a normal XmlDocument is enough for standard DOM based
read/edit.
>
Sincerely,
>
Steven Cheng
>
Microsoft MSDN Online Support Lead
>
>
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
Join Bytes!.
>
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications.
>
==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.--------------------

Quote:

Originally Posted by

From: =?Utf-8?B?TWFyaw==?= <mmodrall@nospam.nospam>
Subject: XmlDocument vs XPathDocument performance
Date: Thu, 5 Jun 2008 08:56:03 -0700

Quote:

Originally Posted by

Hi...

I've been trying to improve the performance of our xml handling, so I've
been doing some timing tests lately and ran across something I thought odd

Quote:

Originally Posted by

XPathDocument seems slightly slower than XmlDocument. I've run the tests
several times and have tried to eliminate extraneous variables like disk
access but every time, XPathDocument comes up slower by a few percent.

I'd expected it to be faster since it's a read-only representation. Am I
doing something wrong?

start = Timers.QueryPerformanceCounter();
for (int idx = 0; idx < 50000; idx++)
{
StringReader sr = new StringReader(xmldoc);
doc = new XmlDocument();
doc.Load(sr);
}
start = Timers.SinceMilliSeconds(start);
Console.WriteLine(start);

start = Timers.QueryPerformanceCounter();
for (int idx = 0; idx < 50000; idx++)
{
StringReader sr = new StringReader(xmldoc);
pDoc = new XPathDocument(sr);
}
start = Timers.SinceMilliSeconds(start);
Console.WriteLine(start);

In other tests, XPathDocument seemed to improve
XslCompiledTransform.Transform performance very slightly, but not enough

Quote:

Originally Posted by

justify the switch given that the loading seemed more expensive...

Thanks
Mark

>
>

Anthony Jones

Guest

n/a Posts

June 27th, 2008
07:20 PM
#4

Re: XmlDocument vs XPathDocument performance

"Mark" <mmodrall@nospam.nospamwrote in message
news:DB816F0B-1CF1-43C3-A337-4187F40EA692@microsoft.com...

Quote:

Originally Posted by

Hi Steven...
>
There are a number of cases, such as applying xsl stylesheets where we

don't

Quote:

Originally Posted by

require the source to be read/write. I'd assumed that since XPathDocument
wouldn't have to support the write side of things that it might be faster

for

Quote:

Originally Posted by

read-only type applications. I was surprised to find that if anything it
seemed slightly slower, and that was odd to me.
>
I can understand given the widespread use that a *lot* of effort went into
optimizing XmlDocument, but I was looking to shave a few cycles going
read-only where I could. I was just surprised that it went the other way.
>

I'm not sure why there not being code present to perform write operations
would have any impact on read performance.

Have you tried examining the memory requirements between the two of them?

I haven't done that myself but I suspect XPathDocument's true strength lies
in its application in a multi-threaded environment such as ASP.NET where
many such documents are being loaded and read. This where memory usage is
likely to have a greater impact on performance than sheer CPU grunt.

--
Anthony Jones - MVP ASP/ASP.NET

=?Utf-8?B?TWFyaw==?=

Guest

n/a Posts

June 27th, 2008
07:20 PM
#5

Re: XmlDocument vs XPathDocument performance

"Anthony Jones" wrote:

Quote:

Originally Posted by

I'm not sure why there not being code present to perform write operations
would have any impact on read performance.
>
Have you tried examining the memory requirements between the two of them?
>
I haven't done that myself but I suspect XPathDocument's true strength lies
in its application in a multi-threaded environment such as ASP.NET where
many such documents are being loaded and read. This where memory usage is
likely to have a greater impact on performance than sheer CPU grunt.

I haven't profiled the memory requirements either, but the theory (perhaps
half-baked) was that a read-only implementation would be able to jettison a
lot of code paths and have fewer checks in the existing methods that go to
support write operations.

I know it's not quite apples to apples, but I thought XPathDocument might be
half way to a sax implementation in terms of being lighter weight and faster.

My first tests included doing a transform on the same ~3k xml document.
Then I separated the times for loading and transforming. XPathDocument was
very slightly faster on transforms but not enough to balance the extra
slowness of getting a loaded instantiation of it.

As I said, that came as a bit of a surprise to me.

Mark

Steven Cheng [MSFT]

Guest

n/a Posts

June 27th, 2008
07:20 PM
#6

Re: XmlDocument vs XPathDocument performance

Hi Mark,

Yes, theoretically XPathDocument only perform read access, however, I think
the Xpath specific implementation here add the most overhead. So far for
the xml API in .net framework, the xml reader/writer is the most light
weight and effecient one(a customized SAX model).

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
Join Bytes!.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications.

==================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.--------------------

Quote:

Originally Posted by

>Subject: Re: XmlDocument vs XPathDocument performance
>Date: Sat, 7 Jun 2008 10:31:00 -0700

Quote:

Originally Posted by

>
>
>"Anthony Jones" wrote:

Quote:

Originally Posted by

>I'm not sure why there not being code present to perform write operations
>would have any impact on read performance.
>>
>Have you tried examining the memory requirements between the two of them?
>>
>I haven't done that myself but I suspect XPathDocument's true strength

lies

Quote:

Originally Posted by

Quote:

Originally Posted by

>in its application in a multi-threaded environment such as ASP.NET where
>many such documents are being loaded and read. This where memory usage

Quote:

Originally Posted by

Quote:

Originally Posted by

>likely to have a greater impact on performance than sheer CPU grunt.

>
>I haven't profiled the memory requirements either, but the theory (perhaps
>half-baked) was that a read-only implementation would be able to jettison

Quote:

Originally Posted by

>lot of code paths and have fewer checks in the existing methods that go to
>support write operations.
>
>I know it's not quite apples to apples, but I thought XPathDocument might

Quote:

Originally Posted by

>half way to a sax implementation in terms of being lighter weight and

faster.

Quote:

Originally Posted by

>
>My first tests included doing a transform on the same ~3k xml document.
>Then I separated the times for loading and transforming. XPathDocument

was

Quote:

Originally Posted by

>very slightly faster on transforms but not enough to balance the extra
>slowness of getting a loaded instantiation of it.
>
>As I said, that came as a bit of a surprise to me.
>
>Mark
>