re-using XmlDocument to load fragments

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.actualLoadingStatus = true;
this.RemoveAll();
this.fEntRefNodesPresent = false;
this.fCDataNodesPresent = false;
this.reportValidity = true;
new XmlLoader().Load(this, reader, this.preserveWhitespace);
}
finally
{
this.IsLoading = false;
this.actualLoadingStatus = false;
this.reportValidity = 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:
Join Bytes!.

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscript...ault.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/subscript...rt/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------

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

Quote: > >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

Quote: >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.

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

names

Quote: >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 > >

Mark wrote:

Quote: 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 XmlDocumentFragment
http://msdn.microsoft.com/en-us/lib...ntfragment.aspx
where you can set the InnerXml property to populate it:
http://msdn.microsoft.com/en-us/lib...t.innerxml.aspx

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

--

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

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 XmlDocumentFragment and from there I
got to XmlDocument.ReadNode(). 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 XmlDocumentFragment 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:

Quote: Mark wrote: > Quote: 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 XmlDocumentFragment http://msdn.microsoft.com/en-us/lib...ntfragment.aspx where you can set the InnerXml property to populate it: http://msdn.microsoft.com/en-us/lib...t.innerxml.aspx > I haven't done any performance test but XmlDocumentFragment is certainly meant to parse fragments and then insert them somewhere into the document tree. > -- > Martin Honnen --- MVP XML http://JavaScript.FAQTs.com/ >

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:
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.
--------------------
Join Bytes!am>

Quote: >References: <94300B79-CCFB-4795-AADD-D3497B59963B@microsoft.com>

<uGDvn$8xIHA.3384@TK2MSFTNGP03.phx.gbl>

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

Quote: > >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 XmlDocumentFragment and from there

I

Quote: >got to XmlDocument.ReadNode(). 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

Quote: >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

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

xml

Quote: >docs and using XmlDocumentFragment or ReadNode to process in-coming text).

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

performance

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

different

Quote: >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

Quote: >the System.Xml code... > >Thanks >Mark > > >"Martin Honnen" wrote: > Quote: >Mark wrote: >> Quote: We've got a lot of places in our code where we read relatively small

xml

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

in every

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

one,

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

fragments.

Quote: Quote: >> >With the DOM implementation there is also XmlDocumentFragment >>

http://msdn.microsoft.com/en-us/lib...ntfragment.aspx

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

http://msdn.microsoft.com/en-us/lib...tfragment.inner
xml.aspx

Quote: Quote: >> >I haven't done any performance test but XmlDocumentFragment is certainly >meant to parse fragments and then insert them somewhere into the >document tree. >> >-- >> > Martin Honnen --- MVP XML > http://JavaScript.FAQTs.com/ >> >