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

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.

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.

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.