XmlDocument vs XPathDocument performance

[=?Utf-8?B?TWFyaw==?=]

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]]

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:
ms****@microsoft.com.

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

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

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

>
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

[=?Utf-8?B?TWFyaw==?=]

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:

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:
ms****@microsoft.com.

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

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

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

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

[Anthony Jones]

"Mark" <mm******@nospam.nospamwrote in message
news:DB**********************************@microsof t.com...

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.

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==?=]

"Anthony Jones" wrote:

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]]

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:
ms****@microsoft.com.

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

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

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

>

"Anthony Jones" wrote:

>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