Groovy XmlSlurper和XmlParser

我搜索了一段时间在这个话题，并找到一些结果，我在邮件的结尾提到。有人可以帮助我准确地回答这三个问题下面列出的情况？

>对于哪些使用XmlSluper的用例比XmlParser更有意义，反之亦然(从API /语法的易用性来看)？
>哪一个更有内存效率？ (看起来像Slurper)
>哪个更快的处理xml？

案例a。当我不得不读几乎所有的节点在xml？

情况b。当我只读几个节点(喜欢使用gpath表达式)？

情况c。当我必须更新/转换xml吗？

只要xml文档不是微不足道的(具有xml的深度和大小的级别)。

资源：

http://www.tutkiun.com/2009/10/xmlparser-and-xmlslurper.html状态：

Difference between XMLParser and XMLSlurper:

There are similarities between XMLParser and XMLSlurper when used for
simple reading but when we use them for advanced reading and when
processing XML documents in other formats there are differences
between two.

XMLParser stores intermediate results after parsing documents. But on
the other hand,

XMLSlurper does not stores internal results after processing XML
documents.

The real,fundamental differences become apparent when processing the
parsed information. That is when processing with direct in-place data
manipulation and processing in a streaming scenario.

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

groovy doc(XmlParser，XmlSlurper)和groovy的网站解释得很好(here和here)，但没有做很好的解释上述问题。

解决方法

XmlSlurper和XmlParser之间的巨大区别在于Parser将创建类似于DOM的东西，而Slurper仅在真正需要的时候尝试创建结构，因此使用被懒惰评估的路径。对于用户来说，两者可以看起来非常相等。不同之处在于，解析器结构仅被评估一次，可以根据需要评估剔除器路径。按需可以在这里读作“更高的内存效率，但更慢”。最终它取决于你做了多少路径/请求。如果你想知道一个属性在XML的某个部分的价值，然后使用它，XmlParser仍然会处理所有和执行你的查询准类DOM。因为很多对象将被创建，内存和cpu消耗。 XmlSlurper不会创建对象，从而节省内存和cpu。如果你需要文档的所有部分，那么slurper会失去优势，因为它会创建至少和解析器一样多的对象。

两者都可以对文档进行转换，但是slurper假定它是一个常量，因此您必须首先写出更改并创建一个新的slurper来读取新的xml。解析器支持立即查看更改。

所以问题(1)的答案，用例，将使用解析器如果你必须处理整个XML，slurper如果只有部分。 API和语法并没有真正发挥作用。 Groovy人试图使这两个用户体验非常相似。此外，如果您希望对XML进行增量更改，则优选解析器超过slurper。

上面的介绍也解释了什么是更高的内存效率，问题(2)。除非你读所有的，否则解析器可能会，但我没有实际的数字，有多大的差异。

还有问题(3)可以通过介绍来回答。如果你有多个延迟评估路径，你必须重新eval，然后这可能比如果你只是像在解析器中导航现有的图形慢。所以解析器可以更快，取决于你的使用。

所以我会说(3a)读几乎所有的节点本身没有太大的区别，因为那时请求是更多的决定因素。但是在情况(3b)中，我会说，如果你只需要读几个节点，slurper更快，因为它不必在内存中创建一个完整的结构，而这本身已经花费了时间和内存。

至于(3c)…这些天，都可以更新/转换XML，这是更快的实际上更多的链接到你需要改变xml的部分。如果很多部分我会说解析器，如果不是，那么也许是俚语。但是如果你想使用slurper将一个属性值从“Fred”更改为“John”，只是为了以后使用相同的slurper查询这个“John”，它不会工作。