Groovy XmlSlurper vs XmlParser


78

Ich habe eine Weile nach diesem Thema gesucht und auch einige Ergebnisse gefunden, die ich am Ende des Beitrags erwähne. Kann mir jemand helfen, diese drei Fragen für die unten aufgeführten Fälle genau zu beantworten?

  1. Für welche Anwendungsfälle ist die Verwendung von XmlSluper sinnvoller als die Verwendung von XmlParser und umgekehrt (aus Sicht der Benutzerfreundlichkeit von API / Syntax)?

  2. Welches ist speichereffizienter? (sieht aus wie Slurper)

  3. Welches verarbeitet die XML schneller?

Fall a. Wann muss ich fast alle Knoten in der XML lesen?

Fall b. wenn ich nur wenige Knoten lesen muss (wie mit gpath expression)?

Fall c. Wann muss ich die XML aktualisieren / transformieren?

vorausgesetzt, das XML-Dokument ist nicht trivial (mit Tiefenstufe und Größe der XML).

Ressourcen :

http://www.tutkiun.com/2009/10/xmlparser-and-xmlslurper.html heißt es:

Unterschied zwischen XMLParser und XMLSlurper:

Es gibt Ähnlichkeiten zwischen XMLParser und XMLSlurper, wenn sie zum einfachen Lesen verwendet werden. Wenn wir sie jedoch zum erweiterten Lesen verwenden und wenn XML-Dokumente in anderen Formaten verarbeitet werden, gibt es Unterschiede zwischen zwei.

XMLParser speichert Zwischenergebnisse nach dem Parsen von Dokumenten. Andererseits,

XMLSlurper speichert keine internen Ergebnisse nach der Verarbeitung von XML-Dokumenten.

Die tatsächlichen, grundlegenden Unterschiede werden bei der Verarbeitung der analysierten Informationen deutlich. Dies ist bei der Verarbeitung mit direkter Datenmanipulation und -verarbeitung in einem Streaming-Szenario der Fall.

http://groovy.dzone.com/news/john-wilson-groovy-and-xml

Das groovige Dokument ( XmlParser , XmlSlurper ) und die Website des Groovys erklären sie gut ( hier und hier ), machen aber keine gute Arbeit bei der Erklärung der oben genannten Frage.

Antworten:


105

Der große Unterschied zwischen XmlSlurper und XmlParser besteht darin, dass der Parser etwas Ähnliches wie ein DOM erstellt, während Slurper versucht, Strukturen nur dann zu erstellen, wenn dies wirklich benötigt wird, und daher Pfade verwendet, die träge ausgewertet werden. Für den Benutzer können beide extrem gleich aussehen. Der Unterschied besteht eher darin, dass die Parser-Struktur nur einmal ausgewertet wird, die Slurper-Pfade können bei Bedarf ausgewertet werden. On Demand kann hier als "speichereffizienter, aber langsamer" gelesen werden. Letztendlich hängt es davon ab, wie viele Pfade / Anforderungen Sie ausführen. Wenn Sie beispielsweise nur den Wert eines Attributs in einem bestimmten Teil des XML kennen und dann damit fertig sein möchten, verarbeitet XmlParser weiterhin alle Daten und führt Ihre Abfrage im Quasi-DOM aus. Dadurch werden viele Objekte erstellt, Speicher und CPU verbrauchen. XmlSlurper erstellt die Objekte nicht und spart somit Speicher und CPU.

Beide können Transformationen für das Dokument durchführen, aber der Slurper geht davon aus, dass es sich um eine Konstante handelt. Daher müssten Sie zuerst die Änderungen ausschreiben und einen neuen Slurper erstellen, um die neue XML-Datei einzulesen. Der Parser unterstützt das sofortige Anzeigen der Änderungen.

Die Antwort auf Frage (1), den Anwendungsfall, wäre also, dass Sie den Parser verwenden, wenn Sie das gesamte XML verarbeiten müssen, den Slurper, wenn nur Teile davon. API und Syntax spielen dabei keine große Rolle. Die Groovy-Leute versuchen, diese beiden in der Benutzererfahrung sehr ähnlich zu machen. Außerdem würden Sie den Parser dem Slurper vorziehen, wenn Sie inkrementelle Änderungen am XML vornehmen möchten.

Das obige Intro erklärt dann auch, was speichereffizienter ist, Frage (2). Der Slurper ist, wenn Sie sowieso nicht alles einlesen, dann kann der Parser, aber ich habe keine tatsächlichen Zahlen darüber, wie groß der Unterschied dann ist.

Auch Frage (3) kann vom Intro beantwortet werden. Wenn Sie mehrere verzögert ausgewertete Pfade haben, müssen Sie diese erneut auswerten. Dies kann langsamer sein, als wenn Sie nur in einem vorhandenen Diagramm wie im Parser navigieren. So kann der Parser je nach Verwendung schneller sein.

Ich würde also sagen (3a), dass das Lesen fast aller Knoten selbst keinen großen Unterschied macht, da dann die Anforderungen der bestimmendere Faktor sind. Aber in Fall (3b) würde ich sagen, dass der Slurper schneller ist, wenn Sie nur einige Knoten lesen müssen, da er keine vollständige Struktur im Speicher erstellen muss, was an sich bereits Zeit und Speicher kostet.

Was (3c) betrifft ... heutzutage können beide das XML aktualisieren / transformieren, was schneller ist und tatsächlich mehr mit der Anzahl der Teile der XML verknüpft ist, die Sie ändern müssen. Wenn viele Teile würde ich den Parser sagen, wenn nicht, dann vielleicht den Slurper. Wenn Sie jedoch beispielsweise einen Attributwert mit dem Slurper von "Fred" in "John" ändern möchten, um später diesen "John" mit demselben Slurper abzufragen, funktioniert dies nicht.


Tolle Erklärung für die Aktualisierung in Bezug auf Slurper, danke. Dies löste mein Problem beim Versuch, Knoten rekursiv zu löschen, wenn sie in einem Slurper "leer" sind, was natürlich nicht funktioniert.
Sandos

3

Ich werde Ihnen eine knackige Antwort geben:

* XML-Parser ist schneller als XML-Slurper.
* XML Slurper verbraucht weniger Speicher als XML-Parser.
* XML-Parser kann XML gleichzeitig analysieren und aktualisieren.
* Für XML Slurper müssen Sie die XML-Dateien nach jedem von Ihnen vorgenommenen Update markieren.
* Wenn Sie Pfadausdrücke verwenden möchten, ist XML Slurper besser als Parser.
* Zum Lesen fast aller Knoten wäre XML-Parser in Ordnung

Ich hoffe es hilft

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.