Groovy XmlSlurper vs XmlParser

我在这个主题上搜索了一段时间，也找到了一些结果，我在文章的最后提到了这些结果。有没有人可以帮助我准确地回答下面列出的三个问题？

  1. 对于哪些用例来说，使用 XmlSluper 比使用 XmlParser 更有意义，反之亦然(从易于使用 API/语法的角度来看) ？

  2. 哪个记忆效率更高? (看起来像 Slurper)

  3. 哪一个处理 xml 更快？

当我必须读取 xml 中的几乎所有节点时，用什么方法？

当我只需要读取几个节点时(比如使用 gpath 表达式) ？

当我必须更新/转换 xml 的情况下？

只要 xml 文档不是无关紧要的(具有 xml 的深度和大小)。

资源 :

Http://www.tutkiun.com/2009/10/xmlparser-and-xmlslurper.html 指出:

XMLParser 和 XMLSlurper 的区别:

XMLParser 和 XMLSlurper 在用于 简单的阅读，但当我们使用他们的高级阅读和时间 处理其他格式的 XML 文档存在差异 两者之间。

XMLParser 在解析文档之后存储中间结果 另一方面,

XMLSlurper 在处理 XML 之后不存储内部结果 文件。

在处理 解析的信息。这是在处理直接就地数据时 流场景中的操作和处理。

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

Groovy doc (XmlParser，XmlSlurper)和 groovy 的站点很好地解释了它们(给你和 给你) ，但是在解释前面提到的问题时没有做很好的工作。

28480 次浏览
小开
最佳答案

The big difference between XmlSlurper and XmlParser is that the Parser will create something similar to a DOM, while Slurper tries to create structures only if really needed and thus uses paths, that are lazily evaluated. For the user both can look extremely equal. The difference is more that the parser structure is evaluated only once, the slurper paths may be evaluated on demand. On demand can be read as "more memory efficient but slower" here. Ultimately it depends how many paths/requests you do. If you for example want only to know the value of an attribute in a certain part of the XML and then be done with it, XmlParser would still process all and execute your query on the quasi DOM. In that a lot of objects will be created, memory and CPU spend. XmlSlurper will not create the objects, thus save memory and CPU. If you need all parts of the document anyway, the slurper loses the advantage, since it will create at least as many objects as the parser would.

Both can do transforms on the document, but the slurper assumes it being a constant and thus you would have to first write the changes out and create a new slurper to read the new xml in. The parser supports seeing the changes right away.

So the answer to question (1), the use case, would be, that you use the parser if you have to process the whole XML, the slurper if only parts of it. API and syntax don't really play much a role in that. The Groovy people try to make those two very similar in user experience. Also you would prefer the parser over the slurper if you want to make incremental changes to the XML.

That intro above also explains then what is more memory efficient, question (2). The slurper is, unless you read in all anyway, then the parser may, but I don't have actual numbers about how big the difference is then.

Also question (3) can be answered by the intro. If you have multiple lazy evaluated paths, you have to eval again, then this can be slower than if you just navigate an existing graph like in the parser. So the parser can be faster, depending on your usage.

So I would say (3a) reading almost all nodes itself makes not much of a difference, since then the requests are the more determining factor. But in case (3b) I would say that the slurper is faster if you just have to read a few nodes, since it will not have to create a complete structure in memory, which in itself already costs time and memory.

As for (3c)...these days both can update/transform the XML. Which is faster is actually more linked to how many parts of the xml you have to change. If many parts I would say the parser, if not, then maybe the slurper. But if you want to for example change an attribute value from "Fred" to "John" with the slurper, just to later query for this "John" using the same slurper, it won't work.

小开

I will give you crisp answers:

  • XML Parser is faster than XML Slurper.
  • XML Slurper consumes less memory than XML Parser.
  • XML Parser can parse and update the XML simultaneously.
  • For XML Slurper you need to MarkupBuild the XMLs after each update you make.
  • When you want to use path expressions XML Slurper would be better than parser.
  • For reading almost all nodes XML Parser would be fine.

Hope it helps


提交答案