Is instantiating XmlDocument expensive?

I have the following function:

public static XmlNode GetXMLNodeFromString(string strXML)
{
    XmlDocument doc = new XmlDocument();
    doc.LoadXml(strXML);
    return doc.DocumentElement;
}

which can be called a million times in a line of code that gets returned from a database call:

while (reader.Read())
{
    myXMLList.Add(GetXMLNodeFromString((string)reader["GMLString"]));
}

Is there a better way than to keep instantiating the xmlDocument for every row? Or is it fine to do so?

I don't want to this:

XmlDocument doc = new XmlDocument();
while (reader.Read())
{
    myXMLList.Add(doc, GetXMLNodeFromString((string)reader["GMLString"]));
}

because in all reality there is a tree of functions that i would have to add it to. Not just GetXMLNodeFromString.

Can i do something like this:

public static class Common
{
    public static XmlDocument doc = new XmlDocument();
    public static X开发者_Python百科mlNode GetXMLNodeFromString(string strXML)
    {
        doc.LoadXml(strXML);
        return doc.DocumentElement;
    }
}

What should i do?

---

I recommend XmlReader if you're having performance problems, as it allows you to parse the XML as it comes in, rather than pre-parsing it and creating an in-memory object model that you're going to have to go back through again anyway. It can require restructuring your code a bit, however, as it gives you sequential (as opposed to random) access. If you don't need random access, it's a good choice.

---

We have found XmlDocument sluggish, but only because we're thrashing it beyond the scope of its design. Instantiating one for every table row however will cause you massive problems. It's a heavyweight class designed for in-place manipulation - which it is very good at - and if you're creating and destroying them faster than a human being could count in their head, you're overworking it.

---

I have experienced performance issue that You might get into. There was foreach loop that used XmlDocument to read xml from files. XmlDocument was instantiated outside of loop. After processing 300 000 files, performance was constantly and progressivly degrading. Putting XmlDocument instantiation inside loop solved the problem. I would never expect this behaviour, but i've measured it and seen it with my own eyes.

Please note that You have to test your own case. Consider:

• that behaviour might depend on xml structure
• maybe You can use XmlReader
• experience i wrote about is on .NET 2.0

I suggest rewriting your code to use XmlReader, because XmlDocument is meant to be used for manipulation. You probably don't need to read milions of rows with XmlDocument and then process 0 or just a few XmlDocuments.