Groovy XmlSlurper vs XmlParser
J'ai cherché pendant un moment sur ce sujet et trouvé des résultats aussi, que je mentionne à la fin du post. Quelqu'un peut-il m'aider à répondre précisément à ces trois questions pour les cas énumérés ci-dessous?
Pour quels cas d'utilisation, utiliser XmlSluper est plus logique que XmlParser et vice-versa (du point de vue de la facilité d'utilisation de l'API/de la syntaxe)?
Lequel est le plus efficace en mémoire? (ressemble à Slurper)
lequel traite le XML plus rapidement?
Cas a. quand je dois lire presque tous les nœuds dans le XML?
Cas b. quand je ne dois lire que quelques nœuds (comme utiliser l'expression gpath)?
Cas c. quand dois-je mettre à jour/transformer le XML?
à condition que le document XML ne soit pas trivial (avec le niveau de profondeur et la taille du XML).
Ressources :
http://www.tutkiun.com/2009/10/xmlparser-and-xmlslurper.html stipule:
Différence entre XMLParser et XMLSlurper:
Il existe des similitudes entre XMLParser et XMLSlurper utilisés avec lecture simple mais quand on les utilise pour la lecture avancée et quand traitement des documents XML dans d'autres formats, il existe des différences entre deux.
XMLParser stocke les résultats intermédiaires après l'analyse des documents. Mais sur l'autre main,
XMLSlurper ne stocke pas les résultats internes après le traitement de XML documents.
Les véritables différences fondamentales deviennent apparentes lors du traitement du fichier informations analysées. C’est lors du traitement avec des données directement sur place manipulation et traitement dans un scénario de streaming.
http://groovy.dzone.com/news/john-wilson-groovy-and-xml
Le doc groovy ( XmlParser , XmlSlurper ) et le site du groovy les expliquent bien ( ici et ici ) mais n'expliquent pas très bien la question susmentionnée.
La grande différence entre XmlSlurper et XmlParser est que l'analyseur créera quelque chose de similaire à un DOM, tandis que Slurper essaie de créer des structures uniquement si cela est vraiment nécessaire et utilise donc des chemins, qui sont évalués paresseux. Pour l'utilisateur, les deux peuvent sembler extrêmement égaux. La différence réside davantage dans le fait que la structure de l'analyseur syntaxique n'est évaluée qu'une seule fois, les chemins de slurper peuvent être évalués à la demande. Sur demande, on peut lire "plus efficace en termes de mémoire mais plus lent". En fin de compte, cela dépend du nombre de chemins/demandes que vous faites. Si, par exemple, vous souhaitez uniquement connaître la valeur d'un attribut dans une certaine partie du code XML, vous en aurez fini avec cela, XmlParser traitera tout et exécutera votre requête sur le quasi-DOM. De nombreux objets seront créés, de la mémoire et de la CPU. XmlSlurper ne créera pas les objets, économisez ainsi de la mémoire et du processeur. De toute façon, si vous avez besoin de toutes les parties du document, le slurper perd l'avantage car il créera au moins autant d'objets que le ferait l'analyseur.
Les deux peuvent effectuer des transformations sur le document, mais le slurper suppose qu'il s'agit d'une constante et vous devez donc d'abord écrire les modifications et créer un nouveau slurper pour lire le nouveau fichier xml. L'analyseur prend en charge l'affichage immédiat des modifications.
Ainsi, la réponse à la question (1), le cas d'utilisation, serait que vous utilisiez l'analyseur si vous devez traiter l'intégralité du XML, le slurper s'il ne s'agit que de parties. Les API et la syntaxe ne jouent pas vraiment un rôle important à cet égard. Les gens de Groovy essaient de rendre ces deux utilisateurs très similaires. De plus, vous préféreriez l’analyseur au slurper si vous souhaitez apporter des modifications incrémentielles au XML.
Cette intro ci-dessus explique également ce qui est plus efficace en termes de mémoire, question (2). Le slurper est, à moins que vous ne lisiez le tout dans tous les cas, l'analyseur peut le faire, mais je n'ai pas de chiffres réels sur l'ampleur de la différence.
Aussi la question (3) peut être répondu par l'intro. Si vous avez plusieurs chemins évalués paresseux, vous devez effectuer une nouvelle évaluation, ce qui peut être plus lent que si vous parcouriez simplement un graphique existant comme dans l'analyseur. Ainsi, l'analyseur peut être plus rapide, en fonction de votre utilisation.
Donc, je dirais que (3a) lire presque tous les nœuds ne fait pas une grande différence, car les requêtes sont alors le facteur le plus déterminant. Mais dans le cas (3b), je dirais que le slurper est plus rapide s'il vous suffit de lire quelques nœuds, car il n'aura pas à créer une structure complète en mémoire, ce qui en soi coûte déjà beaucoup de temps et de mémoire.
En ce qui concerne (3c) ... de nos jours, les deux peuvent mettre à jour/transformer le XML, ce qui est plus rapide est en fait plus lié au nombre de parties du XML que vous devez modifier. Si plusieurs parties, je dirais l'analyseur, sinon, peut-être le slurper. Mais si vous voulez par exemple changer une valeur d'attribut de "Fred" en "John" avec le slurper, une requête ultérieure pour rechercher ce "John" en utilisant le même slurper, cela ne fonctionnera pas.
Je vais vous donner une réponse nette:
* L'analyseur XML est plus rapide que XML Slurper.
* XML Slurper consomme moins de mémoire qu'un analyseur XML.
* L'analyseur XML peut analyser et mettre à jour le XML simultanément.
* Pour XML Slurper, vous devez baliser les XML après chaque mise à jour effectuée.
* Lorsque vous souhaitez utiliser les expressions de chemin, XML Slurper serait préférable à un analyseur.
* Pour lire presque tous les nœuds Un analyseur syntaxique XML conviendrait
J'espère que ça aide