Groovy XmlSlurper vs XmlParser

Question

He buscado durante un tiempo sobre este tema y he encontrado algunos resultados también, que menciono al final de la publicación. ¿Alguien puede ayudarme a responder con precisión estas tres preguntas para los casos que figuran debajo?

1. Para que los casos de uso usando XmlSluper tiene más sentido que XMLParser y viceversa (desde el punto de vista de facilidad de uso de API/Sintaxis)?

2. ¿Cuál es más eficiente con la memoria? (parece Slurper)

3. ¿cuál procesa el xml más rápido?

Case a. cuando tengo que leer casi todos los nodos en el xml?

Caso b. cuando tengo que leer solo algunos nodos (como usar la expresión gpath)

Caso c. cuando tengo que actualizar/transformar el xml?

siempre que el documento xml no sea trivial (con nivel de profundidad y tamaño del xml).

Recursos:

http://www.tutkiun.com/2009/10/xmlparser-and-xmlslurper.html estados:

Diferencia entre XMLParser y XMLSlurper:

hay similitudes entre XMLParser y XMLSlurper cuando se utiliza para lectura simple, pero cuando los usamos para Lectura avanzada y cuando procesan documentos XML en otros formatos, existen diferencias entre dos.

XMLParser almacena los resultados intermedios después del análisis de documentos. Pero en por otro lado,

XMLSlurper no almacena los resultados internos después de procesar documentos XML .

Las diferencias reales y fundamentales se ponen de manifiesto al procesar la información analizada . Eso es cuando se procesa con datos directos in situ manipulación y procesamiento en un escenario de transmisión.

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

El documento maravilloso (XmlParser, XmlSlurper) y del sitio del maravilloso les explica bien (here y here), pero no hace un gran trabajo en la explicación de la pregunta antes mencionada.

Answer 1

La gran diferencia entre XmlSlurper y XmlParser es que el analizador creará algo similar a un DOM, mientras que Slurper intenta crear estructuras solo si es realmente necesario y, por lo tanto, utiliza rutas, que se evalúan de forma perezosa. Para el usuario, ambos pueden verse extremadamente iguales. La diferencia es más que la estructura del analizador se evalúa una sola vez, las rutas de los deslizadores se pueden evaluar a pedido. On demand puede leerse como "más eficiente en memoria pero más lento" aquí. En última instancia, depende de cuántas rutas/solicitudes hagas.Si, por ejemplo, solo quiere saber el valor de un atributo en una determinada parte del XML y luego terminarlo, XmlParser procesará todo y ejecutará su consulta en el casi DOM. En eso se crearán muchos objetos, memoria y gasto de CPU. XmlSlurper no creará los objetos, así ahorrará memoria y CPU. Si necesita todas las partes del documento de todos modos, el tragamonedas pierde la ventaja, ya que creará al menos tantos objetos como lo haría el analizador.

Ambos pueden hacer transformaciones en el documento, pero el slurper asume que es una constante y por lo tanto, primero debe escribir los cambios y crear un nuevo slurper para leer el nuevo xml. El analizador admite ver los cambios correctos lejos.

Así que la respuesta a la pregunta (1), el caso de uso, sería que usted usa el analizador si tiene que procesar todo el XML, mientras que el slurper solo es parte de él. La API y la sintaxis en realidad no juegan un papel muy importante en eso. La gente de Groovy intenta hacer que esos dos sean muy similares en la experiencia del usuario. También preferiría el analizador sobre el slurper si desea realizar cambios incrementales al XML.

Esa introducción anterior también explica qué es más eficiente en la memoria, pregunta (2). El slurper es, a menos que lo leas de todos modos, entonces el analizador puede, pero no tengo los números reales sobre cuán grande es la diferencia en ese momento.

También la pregunta (3) puede ser respondida por la introducción. Si tiene varias rutas evaluadas de forma diferida, tiene que evaluar nuevamente, entonces esto puede ser más lento que si solo navega un gráfico existente como en el analizador. Por lo tanto, el analizador puede ser más rápido, según su uso.

Así que diría que (3a) leer casi todos los nodos no hace mucha diferencia, ya que las solicitudes son el factor más determinante. Pero en el caso (3b), diría que la tragamonedas es más rápida si solo tiene que leer algunos nodos, ya que no tendrá que crear una estructura completa en la memoria, que en sí misma ya le cuesta tiempo y memoria.

En cuanto a (3c) ... estos días ambos pueden actualizar/transformar el XML, que es más rápido en realidad está más relacionado con la cantidad de partes del xml que tiene que cambiar. Si hay muchas partes, diría que el analizador sintáctico, si no, entonces tal vez el tragador. Pero si quiere, por ejemplo, cambiar el valor de un atributo de "Fred" a "John" con el slurper, solo para consultar más adelante este "John" usando el mismo slurper, no funcionará.