>对于哪些使用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)，但没有做很好的解释上述问题。
解决方法
两者都可以对文档进行转换，但是slurper假定它是一个常量，因此您必须首先写出更改并创建一个新的slurper来读取新的xml。解析器支持立即查看更改。
所以问题(1)的答案，用例，将使用解析器如果你必须处理整个XML，slurper如果只有部分。 API和语法并没有真正发挥作用。 Groovy人试图使这两个用户体验非常相似。此外，如果您希望对XML进行增量更改，则优选解析器超过slurper。
上面的介绍也解释了什么是更高的内存效率，问题(2)。除非你读所有的，否则解析器可能会，但我没有实际的数字，有多大的差异。
还有问题(3)可以通过介绍来回答。如果你有多个延迟评估路径，你必须重新eval，然后这可能比如果你只是像在解析器中导航现有的图形慢。所以解析器可以更快，取决于你的使用。
所以我会说(3a)读几乎所有的节点本身没有太大的区别，因为那时请求是更多的决定因素。但是在情况(3b)中，我会说，如果你只需要读几个节点，slurper更快，因为它不必在内存中创建一个完整的结构，而这本身已经花费了时间和内存。
至于(3c)…这些天，都可以更新/转换XML，这是更快的实际上更多的链接到你需要改变xml的部分。如果很多部分我会说解析器，如果不是，那么也许是俚语。但是如果你想使用slurper将一个属性值从“Fred”更改为“John”，只是为了以后使用相同的slurper查询这个“John”，它不会工作。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
