re-using XmlDocument to load fragments

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

Hi...

We've got a lot of places in our code where we read relatively small xml
user preference blocks. Currently that's creating a new XmlDocument in every
spot. I was thinking we might see some speed improvements by having one,
central XmlDocument and using doc.ReadNode() to process all of the fragments.

Other than pumping up the NameTable with a mish-mash of different node names
and namespaces, are there any other implications I'm missing?

As an aside, I noticed that doing doc.Load() on a dom more than once keeps
the same NameTable object. What does the XmlDocument do internally with
multiple .Load() calls? Does it empty its internal state object, or just
accrete more?

thanks
Mark

[Steven Cheng [MSFT]]

Hi Mark,

As for the XmlDocument class, the Load method does do some cleaning up
works such as remove the child nodes and set some properties off. Here is
the code picked from the reflector:
=============
public virtual void Load(XmlReader reader)
{
try
{
this.IsLoading = true;
this.actualLoad ingStatus = true;
this.RemoveAll( );
this.fEntRefNod esPresent = false;
this.fCDataNode sPresent = false;
this.reportVali dity = true;
new XmlLoader().Loa d(this, reader, this.preserveWh itespace);
}
finally
{
this.IsLoading = false;
this.actualLoad ingStatus = false;
this.reportVali dity = true;
}
}
=============== ===

Also, the NameTable seems is initialized at XmlDocument's constructor(it
will add some basic namespace mappings there). I think the xmlDocument's
constructor is not very expensive, therefore, if you haven't obviouly
detect performance hit via the XmlDocument creation, I suggest you remain
creating new instance when loading a new xml document/file.

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****@microsof t.com.

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

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
=============== =============== =============== =====
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

>From: =?Utf-8?B?TWFyaw==?= <mm******@nospa m.nospam>
Subject: re-using XmlDocument to load fragments
Date: Thu, 5 Jun 2008 09:10:00 -0700

>
Hi...

We've got a lot of places in our code where we read relatively small xml
user preference blocks. Currently that's creating a new XmlDocument in

every

>spot. I was thinking we might see some speed improvements by having one,
central XmlDocument and using doc.ReadNode() to process all of the

fragments.

>
Other than pumping up the NameTable with a mish-mash of different node

names

>and namespaces, are there any other implications I'm missing?

As an aside, I noticed that doing doc.Load() on a dom more than once keeps
the same NameTable object. What does the XmlDocument do internally with
multiple .Load() calls? Does it empty its internal state object, or just
accrete more?

thanks
Mark

[Martin Honnen]

Mark wrote:

We've got a lot of places in our code where we read relatively small xml
user preference blocks. Currently that's creating a new XmlDocument in every
spot. I was thinking we might see some speed improvements by having one,
central XmlDocument and using doc.ReadNode() to process all of the fragments.

With the DOM implementation there is also XmlDocumentFrag ment
http://msdn.microsoft.com/en-us/libr...tfragment.aspx
where you can set the InnerXml property to populate it:
http://msdn.microsoft.com/en-us/libr....innerxml.aspx

I haven't done any performance test but XmlDocumentFrag ment is certainly
meant to parse fragments and then insert them somewhere into the
document tree.

--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/

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

Thank you, Steven and Martin for your responses.

I know this may be a specialized case, but we had implemented jabber http
tunneling originally using a fresh XmlDocument for each request and it was
unusably slow. Wen Yuan pointed me at XmlDocumentFrag ment and from there I
got to XmlDocument.Rea dNode(). Getting away from a fresh document per
request made a *huge* difference in performance.

Now, one of the advantages of that specialized case is that I knew all the
requests were adhering to the same schema, so there would be 100% reuse of
the NameTable and namespace manager. I'm not sure, but I suspect that had a
fair bit to do with the speed improvement.

In another app with more general uses, we have lots and lots of little
XmlDocuments popping in and out of existence to handle user preferences. I
was thinking of applying the same trick there (keeping one or two static xml
docs and using XmlDocumentFrag ment or ReadNode to process in-coming text).
Since these xml fragments don't come from one coherent schema, I was
wondering if I would likely have the opposite effect - diluting performance
by having a nametable and namespace manager polluted with a lot of different
values.

It would be quite a large undertaking to retool the system, so I was
wondering what the opinions were of those more familiar with the internals of
the System.Xml code...

Thanks
Mark
"Martin Honnen" wrote:

Mark wrote:

We've got a lot of places in our code where we read relatively small xml
user preference blocks. Currently that's creating a new XmlDocument in every
spot. I was thinking we might see some speed improvements by having one,
central XmlDocument and using doc.ReadNode() to process all of the fragments.

With the DOM implementation there is also XmlDocumentFrag ment
http://msdn.microsoft.com/en-us/libr...tfragment.aspx
where you can set the InnerXml property to populate it:
http://msdn.microsoft.com/en-us/libr....innerxml.aspx

I haven't done any performance test but XmlDocumentFrag ment is certainly
meant to parse fragments and then insert them somewhere into the
document tree.

--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/

[Steven Cheng [MSFT]]

Thanks for your reply Mark,

Then, I think your current approach of reusing the xml document object is
reasonable.

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****@microsof t.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.
--------------------
[e-mail]>

>References: <94************ *************** *******@microso ft.com>

<uG************ **@TK2MSFTNGP03 .phx.gbl>

>Subject: Re: re-using XmlDocument to load fragments
Date: Fri, 6 Jun 2008 06:10:01 -0700

>
Thank you, Steven and Martin for your responses.

I know this may be a specialized case, but we had implemented jabber http
tunneling originally using a fresh XmlDocument for each request and it was
unusably slow. Wen Yuan pointed me at XmlDocumentFrag ment and from there

I

>got to XmlDocument.Rea dNode(). Getting away from a fresh document per
request made a *huge* difference in performance.

Now, one of the advantages of that specialized case is that I knew all the
requests were adhering to the same schema, so there would be 100% reuse of
the NameTable and namespace manager. I'm not sure, but I suspect that had

a

>fair bit to do with the speed improvement.

In another app with more general uses, we have lots and lots of little
XmlDocuments popping in and out of existence to handle user preferences.

I

>was thinking of applying the same trick there (keeping one or two static

xml

>docs and using XmlDocumentFrag ment or ReadNode to process in-coming text).

>Since these xml fragments don't come from one coherent schema, I was
wondering if I would likely have the opposite effect - diluting

performance

>by having a nametable and namespace manager polluted with a lot of

different

>values.

It would be quite a large undertaking to retool the system, so I was
wondering what the opinions were of those more familiar with the internals

of

>the System.Xml code...

Thanks
Mark
"Martin Honnen" wrote:

>Mark wrote:

We've got a lot of places in our code where we read relatively small

xml

user preference blocks. Currently that's creating a new XmlDocument

in every

spot. I was thinking we might see some speed improvements by having

one,

central XmlDocument and using doc.ReadNode() to process all of the

fragments.

>>
With the DOM implementation there is also XmlDocumentFrag ment

http://msdn.microsoft.com/en-us/libr...tfragment.aspx

>where you can set the InnerXml property to populate it:

http://msdn.microsoft.com/en-us/libr...fragment.inner
xml.aspx

>>
I haven't done any performance test but XmlDocumentFrag ment is certainly
meant to parse fragments and then insert them somewhere into the
document tree.

--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/