What is more efficient for parsing Xml, XPath with XmlDocuments, XSLT or Linq?

Question

My shared memory, implemented in C++, has a linked list. While I am adding elements to linked list, does its size change automatically ( as if it was an ordinary heap allocated element ) or it should contain only fixed size structures like a fixed size array ?

Solution 1

The absolute fastest way to query an XML document is the hardest: write a method that uses an XmlReader to process the input stream, and have it process nodes as it reads them. This is the way to combine parsing and querying into a single operation. (Simply using XPath doesn't do this; both XmlDocument and XPathDocument parse the document in their Load methods.) This is usually only a good idea if you're processing extremely large streams of XML data.

All three methods you've describe perform similarly. XSLT has a lot of room to be the slowest of the lot, because it lets you combine the inefficiencies of XPath with the inefficiencies of template matching. XPath and LINQ queries both do essentially the same thing, which is linear searching through enumerable lists of XML nodes. I would expect LINQ to be marginally faster in practice because XPath is interpreted at runtime while LINQ is interpreted at compile-time.

But in general, how you write your query is going to have a much greater impact on execution speed than what technology you use.

The way to write fast queries against XML documents is the same whether you're using XPath or LINQ: formulate the query so that as few nodes as possible get visited during its execution. It doesn't matter which technology you use: a query that examines every node in the document is going to run a lot slower than one that examines only a small subset of them. Your ability to do that is more dependent on the structure of the XML than anything else: a document with a navigable hierarchy of elements is generally going to be a lot faster to query than one whose elements are all children of the document element.

Edit:

While I'm pretty sure I'm right that the absolute fastest way to query an XML is the hardest, the real fastest (and hardest) way doesn't use an XmlReader; it uses a state machine that directly processes characters from a stream. Like parsing XML with regular expressions, this is ordinarily a terrible idea. But it does give you the option of exchanging features for speed. By deciding not to handle those pieces of XML that you don't need for your application (e.g. namespace resolution, expansion of character entities, etc.) you can build something that will seek through a stream of characters faster than an XmlReader would. I can think of applications where this is even not a bad idea, though there I can't think of many.

Solution 2

LinqToXml queries work against the IEnumerable contract... most of its operations are O(N) because they require iteration over the IEnumerable.

If what you're starting with is a string containing xml, in order to work with it in Linq, you would need to parse it into the full object graph using XElement.Parse, then iterate over parts of it (to filter it, for example).

My understanding of XPath is that it will filter while parsing, which could be very advantageous from a performance standpoint. The full object graph need not be constructed.

Solution 3

I haven't actually tested it, but Linq is primarily a compiler code-gen type feature, and so it should be comparable to using an XmlDocument and XPath queries.

The primary value of Linq is that it provides compile-time verification of your query statements, which neither XPath nor XSLT can provide.

I would think that if performance is a concern, your decision would be based on the task at hand. For example, retrieving a single value from an XML document might be fastest using a single XPath query, but translating XML data into an HTML page would be faster using XSLT.

Comments

[László Papp]

Do you know how linkedlists work? When a new element is added, it is just added dynamically, and a pointer will point to it from a previous data element. That should answer your question, yeah? If not, could you please elaborate what the real question is?

[Carlos]

You should read my question more carefully. I do know very well how linked lists work. In normal life, we create linked list on the heap with dynamic memory allocation. However in my question I have stated that I have a Linked list created in shared memory area and as you might guess shared memory region has a fixed size which is different than heap. So I am asking that is it possible to initialize shared memory region such that when we add new insertions, its initial size will not be a problem. I mean it will behave like the heap. But I don t think this is possible.

[László Papp]

Well, of course it is fixed size. Otherwise, you will need to create another bigger one if you cannot do big enough in advance.

[Carlos]

So please read more carefully before you attempt to answer questions my friend.

[László Papp]

I carefully read your stuff which I personally think is a bit sloppy, and somewhat self-evident. That is why I asked for clarification.

[Carlos]

That is also why I did directly ignore your unrelated answers.

[László Papp]

Good, so I hope you are happier now.

[Carlos]

Thanks, your answer is as I guess unfortunately.