it-swarm.dev

XmlSlurper Groovy vs XmlParser

Eu procurei por um tempo sobre este tema e encontrei alguns resultados também, o que estou mencionando no final do post. Alguém pode me ajudar a responder com precisão essas três perguntas para os casos listados abaixo?

  1. Para quais casos de uso usando XmlSluper faz mais sentido do que XmlParser e vice-versa (do ponto de vista da facilidade de uso da API/sintaxe)?

  2. Qual deles é mais eficiente em memória? (parece com o Slurper)

  3. qual processa o xml mais rápido?

Caso a. quando eu tenho que ler quase todos os nós no xml?

Caso b. quando tenho que ler apenas alguns nós (como usar a expressão gpath)?

Caso c. quando tenho que atualizar/transformar o xml?

desde que o documento xml não seja trivial (com nível de profundidade e tamanho do xml).

Recursos

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

Diferença entre XMLParser e XMLSlurper:

Existem similaridades entre XMLParser e XMLSlurper quando usadas para Leitura simples, mas quando as usamos para leitura avançada e quando Processamos documentos XML em outros formatos, há diferenças Entre dois.

O XMLParser armazena resultados intermediários após a análise de documentos. Mas por outro lado, 

O XMLSlurper não armazena resultados internos depois de processar documentos XML .

As diferenças reais e fundamentais se tornam aparentes ao processar a informação analisada . Isso é quando o processamento com manipulação direta de dados in-loco E processamento em um cenário de streaming.

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

O groovy doc ( XmlParser , XmlSlurper ) e o site do groovy os explica bem ( aqui e aqui ), mas não faz um ótimo trabalho ao explicar a questão acima mencionada.

71
kunal

A grande diferença entre XmlSlurper e XmlParser é que o Parser irá criar algo semelhante a um DOM, enquanto o Slurper tenta criar estruturas apenas se realmente for necessário e, portanto, usa caminhos, que são avaliados com preguiça. Para o usuário, ambos podem parecer extremamente iguais. A diferença é mais que a estrutura do analisador é avaliada apenas uma vez, os caminhos do slurper podem ser avaliados sob demanda. On demand pode ser lido como "mais memória eficiente, mas mais lento" aqui. Em última análise, depende de quantos caminhos/solicitações você faz. Se, por exemplo, você quiser apenas saber o valor de um atributo em uma determinada parte do XML e, em seguida, acabar com ele, o XmlParser ainda processaria tudo e executaria sua consulta no quasi DOM. Em que muitos objetos serão criados, memória e gastos com CPU. XmlSlurper não criará os objetos, economizando memória e CPU. Se você precisar de todas as partes do documento, o slurper perderá a vantagem, pois criará pelo menos tantos objetos quanto o parser. 

Ambos podem fazer transformações no documento, mas o slurper assume que ele é uma constante e, portanto, você teria que primeiro gravar as alterações e criar um novo slurper para ler o novo xml. O analisador suporta ver as alterações imediatamente.

Portanto, a resposta para questionar (1), o caso de uso, seria que você usaria o analisador se tiver que processar todo o XML, o slurper se apenas partes dele. A API e a sintaxe não desempenham um papel muito importante nisso. As pessoas do Groovy tentam fazer com que as duas sejam muito semelhantes na experiência do usuário. Além disso, você preferiria o analisador sobre o slurper se quiser fazer alterações incrementais no XML.

Essa introdução acima também explica então o que é mais memória eficiente, pergunta (2). O slurper é, a menos que você leia tudo de qualquer maneira, então o parser pode, mas eu não tenho números reais sobre quão grande é a diferença então.

Também a questão (3) pode ser respondida pela introdução. Se você tem vários caminhos avaliados com preguiça, você tem que eval novamente, então isso pode ser mais lento do que se você apenas navegasse em um gráfico existente como no analisador. Assim, o analisador pode ser mais rápido, dependendo do seu uso.

Então eu diria que (3a) ler quase todos os nós em si não faz muita diferença, desde então os pedidos são o fator mais determinante. Mas no caso (3b) eu diria que o slurper é mais rápido se você tiver que ler apenas alguns nós, já que ele não terá que criar uma estrutura completa na memória, que por si só já custa tempo e memória.

Quanto a (3c) ... atualmente ambos podem atualizar/transformar o XML, que é mais rápido, na verdade, mais vinculado a quantas partes do xml você precisa alterar. Se muitas partes eu diria o parser, se não, então talvez o slurper. Mas se você quiser, por exemplo, alterar um valor de atributo de "Fred" para "John" com o slurper, apenas para consultar mais tarde esse "John" usando o mesmo slurper, ele não funcionará.

97
blackdrag

Eu vou lhe dar uma resposta nítida:

* O XML Parser é mais rápido que o XML Slurper.
* O XML Slurper consome menos memória que o XML Parser.
* XML Parser pode analisar e atualizar o XML simultaneamente.
* Para o Slurper XML que você precisa para o MarkupBuild O XML após cada atualização que você faz.
* Quando você quiser usar expressões de caminho XML Slurper seria melhor que o analisador.
* Para ler quase todos os nós, o XML Parser ficaria bem

Espero que ajude

0
srinivasan