Die absolut schnellste Methode zum Abfragen eines XML-Dokuments ist die schwierigste: Schreiben Sie eine Methode, die einen XmlReader verwendet, um den Eingabestream zu verarbeiten und Prozessknoten beim Lesen zu verarbeiten. Auf diese Weise können Analyse und Abfrage zu einer einzigen Operation kombiniert werden. (Die Verwendung von XPath führt dies nicht aus; sowohl XmlDocument als auch XPathDocument analysieren das Dokument in den Load-Methoden.) Dies ist normalerweise nur dann sinnvoll, wenn Sie extrem große XML-Datenströme verarbeiten.
Alle drei beschriebenen Methoden funktionieren ähnlich. XSLT bietet viel Platz, um das langsamste zu sein, da Sie die Ineffizienzen von XPath mit den Ineffizienzen des Template-Matchings kombinieren können. XPath- und LINQ-Abfragen machen im Wesentlichen dasselbe, nämlich das lineare Durchsuchen von aufzählbaren Listen von XML-Knoten. Ich würde erwarten, dass LINQ in der Praxis geringfügig schneller ist, da XPath zur Laufzeit interpretiert wird, während LINQ zur Kompilierzeit interpretiert wird.
Aber im Allgemeinen, wie Sie Ihre Abfrage schreiben wird einen viel größeren Einfluss auf die Ausführungsgeschwindigkeit als die Technologie, die Sie verwenden.
Die Möglichkeit, schnelle Abfragen für XML-Dokumente zu schreiben, ist dieselbe, unabhängig davon, ob Sie XPath oder LINQ verwenden: formulieren Sie die Abfrage so, dass während der Ausführung so wenig Knoten wie möglich besucht werden. Es spielt keine Rolle, welche Technologie Sie verwenden: Eine Abfrage, die jeden Knoten im Dokument untersucht, wird viel langsamer laufen als eine, die nur eine kleine Teilmenge davon untersucht. Ihre Fähigkeit, dies zu tun, hängt mehr von der Struktur des XML ab als alles andere: Ein Dokument mit einer navigierbaren Hierarchie von Elementen wird im Allgemeinen viel schneller abgefragt werden als eines, dessen Elemente alle untergeordneten Elemente des Dokumentelements sind.
Edit:
Während ich bin mir ziemlich sicher, dass ich Recht habe, dass der absolute schnellste Weg, um eine XML-Abfrage ist die härteste, die wirkliche schnellste (und schwierigsten) Art und Weise verwendet keine XmlReader; Es verwendet eine Zustandsmaschine, die Zeichen aus einem Stream direkt verarbeitet. Wie das Analysieren von XML mit regulären Ausdrücken ist das normalerweise eine schreckliche Idee. Aber es gibt Ihnen die Möglichkeit, Funktionen für Geschwindigkeit auszutauschen. Wenn Sie sich entscheiden, diese XML-Teile nicht zu verarbeiten, die Sie für Ihre Anwendung nicht benötigen (z. B. Namespace-Auflösung, Erweiterung von Zeicheneinheiten usw.), können Sie etwas erstellen, das schneller durch einen Zeichenstrom sucht als ein XmlReader. Ich kann mir Anwendungen vorstellen, bei denen das überhaupt keine schlechte Idee ist, obwohl ich an viele nicht denken kann.
Siehe auch http://stackoverflow.com/questions/407350/how-best-to-use-xpath-with-y-large-xml-files-in-c/716659#716659, auf den ich den Leser hinweisen XPathReader, der die Geschwindigkeit von XmlReader mit der Benutzerfreundlichkeit von XPath kombiniert –
XPathReader ist eine wirklich hervorragende Idee, die mir völlig unbekannt war. Danke, dass du mich darauf hingewiesen hast. –
Die Verfügbarkeit von PLINQ (Parallel Linq) in .NET 4.0 macht Linq zu einer noch attraktiveren Option als zuvor. Um fair zu sein, wirft PLINQ wirklich mehr Pferdestärken auf das Problem; Es macht den Parser nicht effizienter. Aber insgesamt ist Linq ein gutes Gleichgewicht zwischen Kürze und Leistung. –