tags:

views:

224

answers:

5

If I do

XPathDocument doc = new XPathDocument("filename.xml");

Does that load the entire document into memory? I'm writing a mobile phone app and the document might store lots of data that doesn't ever need to all be loaded at the same time. Mobile phones don't usually have too much ram!

+2  A: 

Yes, the whole XML document is represented in memory.

One solution is to split a large XML document into many smaller ones.

Or, alternatively, you may write your own XmlReader that will ignore unwanted subtrees. You can pass this XmlReader as argument to the XpathDocument() constructor -- need to camouflage it as TextReader.

Dimitre Novatchev
Is there some better way to load certain parts of an xml document? Like just certain tags?
Wires
@wires: Not a system solution, but you may write your own XmlReader that will ignore unwanted subtrees. You can pass this XmlReader as argument to the XpathDocument() constructor -- need to camouflage it as TextReader. :)
Dimitre Novatchev
A: 

http://msdn.microsoft.com/en-us/library/system.xml.xpath.xpathdocument_members.aspx

"Provides a fast, read-only, in-memory representation of an XML document by using the XPath data model."

Brett Widmeier
A: 

You might want to try the other constructor XPathDocument(stream). Streaming the document won't use as much memory.

Maybe you wan't to take a look at Linq to XML, as it's easier, faster to code and make more beautiful code than to use SAX/DOM parsing. See this post : http://stackoverflow.com/questions/2606959/how-to-store-data-without-using-database-and-how-to-retrieve-them/2607043#2607043

Frank
Using the Stream constructor has no effect on the amount of memory that the XPathDocument will use. And Linq to XML is not faster than SAX (or using an XmlReader, which is what's used in .NET instead of SAX), nor - unlike using an XmlReader - does it avoid reading the entire document into memory.
Robert Rossney
Regarding the stream constructor, that's why I've written "you might want". On the other hand, I think you should take a look on how Linq streams the data and doesn't load a complete file to memory.
Frank
The XStreamingElement class can write a very large XML document without creating an entire in-memory XML document. But it's not used for reading. When most people talk about Linq to XML (as in both examples you linked to), they're talking about XDocument, and XDocument does in fact load the entire XML document into memory. Is there some awesome Linq object I'm overlooking? Believe me, this is something I'd love to be wrong about.
Robert Rossney
+2  A: 

You probably want something more like the System.Xml.XmlReader.

Ishmael
A: 

You might want to look at the XStreamingElement of LINQ to XML:

Represents elements in an XML tree that supports deferred streaming output.

This class allows you to create an XML tree that supports deferred streaming output. You use this class to create an XML tree in a very similar fashion to creating an XML tree using XElement. However, there is a fundamental difference. When you use a LINQ query to specify content when creating an XML tree using XElement, the query variable is iterated at the time of construction of the XML tree, and the results of the query are added to the XML tree. In contrast, when you create an XML tree using XStreamingElement, a reference to the query variable is stored in the XML tree without being iterated. Queries are iterated only upon serialization. This allows you to create larger XML trees while maintaining a smaller memory footprint.

If you are streaming from an input source, such as a text file, then you can read a very large text file, and generate a very large XML document while maintaining a small memory footprint.

John Saunders