read - Groovy XmlSlurper contra XmlParser

groovy read xml

Question

Busqué un momento sobre este tema y también encontré algunos resultados, 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 qué casos de uso usar XmlSluper tiene más sentido que XmlParser y viceversa (desde el punto de vista de la facilidad de uso de API / Sintaxis)?

2. ¿Cuál es más eficiente con la memoria? (se parece a 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 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 declara:

Diferencia entre XMLParser y XMLSlurper:

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

XMLParser almacena resultados intermedios después de analizar 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 directo de datos in situ en un escenario de transmisión.

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

El doc groovy ( XmlParser , XmlSlurper ) y el sitio de groovy los explican bien ( here y here ) pero no hacen un gran trabajo al explicar 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 tragamonedas asume que es una constante y, por lo tanto, primero debe escribir los cambios y crear una nueva corredera 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 usted usa el analizador si tiene que procesar todo el XML, mientras que el agente limitador es solo 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.

La 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) ... en estos días, ambos pueden actualizar / transformar el XML, que es más rápido 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 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á.