Groovy XmlSlurper vs XmlParser

78

Busqué un tiempo sobre este tema y también encontré algunos resultados, que menciono al final de la publicación. ¿Puede alguien ayudarme a responder con precisión estas tres preguntas para los casos que se enumeran a continuación?

  1. ¿Para qué casos de uso el uso de XmlSluper tiene más sentido que XmlParser y viceversa (desde el punto de vista, la facilidad de uso de API / Syntax)?

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

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

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

Caso b. cuando tengo que leer solo unos pocos 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 dice:

Diferencia entre XMLParser y XMLSlurper:

Existen similitudes entre XMLParser y XMLSlurper cuando se usan para lectura simple, pero cuando los usamos para lectura avanzada y cuando procesamos documentos XML en otros formatos, existen diferencias entre dos.

XMLParser almacena resultados intermedios después de analizar los documentos. Pero en la otra mano,

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

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

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

El documento groovy ( XmlParser , XmlSlurper ) y el sitio de groovy los explica bien ( aquí y aquí ) pero no hace un gran trabajo al explicar la pregunta antes mencionada.

kdabir
fuente

Respuestas:

105

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 sintáctico se evalúa solo una vez, las rutas de los slurper pueden evaluarse a pedido. Bajo demanda se puede leer aquí como "más eficiente en memoria pero más lento". En última instancia, depende de cuántas rutas / solicitudes realice. Si, por ejemplo, solo desea conocer el valor de un atributo en una determinada parte del XML y luego terminar con él, XmlParser aún procesará todo y ejecutará su consulta en el cuasi DOM. En eso se crearán muchos objetos, se gastará memoria y CPU. XmlSlurper no creará los objetos, por lo que ahorrará memoria y CPU.

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

Entonces, la respuesta a la pregunta (1), el caso de uso, sería que use el analizador si tiene que procesar todo el XML, el slurper si solo partes de él. La API y la sintaxis no juegan mucho en eso. La gente de Groovy intenta hacer que esos dos sean muy similares en la experiencia del usuario. Además, preferiría el analizador sintáctico sobre el deslizador si desea realizar cambios incrementales en el XML.

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

Además, la intro puede responder a la pregunta (3). Si tiene varias rutas evaluadas diferidas, debe evaluar nuevamente, entonces esto puede ser más lento que si simplemente navega por un gráfico existente como en el analizador. Por lo tanto, el analizador puede ser más rápido, según su uso.

Entonces yo diría que (3a) leer casi todos los nodos en sí no hace mucha diferencia, ya que entonces las solicitudes son el factor más determinante. Pero en el caso (3b) diría que el slurper es más rápido si solo tienes que leer unos pocos nodos, ya que no tendrá que crear una estructura completa en memoria, lo que en sí mismo ya cuesta tiempo y memoria.

En cuanto a (3c) ... en estos días ambos pueden actualizar / transformar el XML, que es más rápido y en realidad está más vinculado a la cantidad de partes del xml que tiene que cambiar. Si hay muchas partes, diría que el analizador, si no, quizás el sordo. Pero si desea, por ejemplo, cambiar el valor de un atributo de "Fred" a "John" con el slurper, solo para consultar posteriormente este "John" utilizando el mismo slurper, no funcionará.

blackdrag
fuente
Impresionante explicación de la actualización en lo que respecta a slurper, gracias. Esto resolvió mi problema al intentar eliminar nodos de forma recursiva cuando estaban "vacíos" en un slurper, lo que por supuesto no funcionará.
Sandos
3

Te daré respuestas claras:

* XML Parser es más rápido que XML Slurper.
* XML Slurper consume menos memoria que XML Parser.
* XML Parser puede analizar y actualizar el XML simultáneamente.
* Para XML Slurper, debe marcar el código XML después de cada actualización que realice.
* Cuando desee utilizar Path Expressions XML Slurper sería mejor que el analizador.
* Para leer casi todos los nodos, el analizador XML estaría bien

Espero eso ayude

srinivasan
fuente