Groovy XmlSlurper 与 XmlParser

发布于 2024-12-06 10:59:14 字数 1522 浏览 3 评论 0原文

我在这个主题上搜索了一段时间,也发现了一些结果,我在帖子末尾提到了这一点。有人可以帮我针对下面列出的案例准确回答这三个问题吗?

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

  2. 哪一个的内存效率更高? (看起来像 Slurper)

  3. 哪一个处理 xml 的速度更快?

案例一.当我必须读取 xml 中的几乎所有节点时?

情况 B.当我只需要读取几个节点时(例如使用 gpath 表达式)?

案例 C.当我必须更新/转换 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 文档 (XmlParserXmlSlurper)和groovy 的网站很好地解释了它们(此处此处 )但在解释上述问题方面并没有做得很好。

I searched for a while on this topic and found some results too, which I am mentioning at the end of post. Can someone help me precisely answer these three questions for the cases listed below them?

  1. For which use-cases using XmlSluper makes more sense than XmlParser and vice-versa (from point of view ease of use of API/Syntax)?

  2. Which one is more memory efficient? (looks like Slurper)

  3. which one processes the xml faster?

Case a. when I have to read almost all nodes in the xml?

Case b. when I have to read just few nodes (like using gpath expression)?

Case c. when I have to update/transform the xml?

provided the xml document is not trivial one (with level of depths and size of the xml).

Resources :

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

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

The groovy doc (XmlParser, XmlSlurper) and the groovy's site explains them well (here and here)but does not do a great job in explaining the aforementioned question.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

非要怀念 2024-12-13 10:59:14

XmlSlurper 和 XmlParser 之间的最大区别在于,Parser 将创建类似于 DOM 的东西,而 Slurper 仅在真正需要时才尝试创建结构,因此使用延迟评估的路径。对于用户来说,两者看起来极其平等。不同之处在于解析器结构仅评估一次,slurper 路径可以根据需要评估。此处的按需可以理解为“内存效率更高但速度更慢”。最终这取决于您执行的路径/请求的数量。例如,如果您只想知道 XML 特定部分中某个属性的值,然后再处理它,XmlParser 仍会处理所有内容并在准 DOM 上执行查询。由于会创建大量对象,因此会消耗内存和 CPU。 XmlSlurper不会创建对象,从而节省内存和CPU。如果您无论如何都需要文档的所有部分,那么 slurper 就会失去优势,因为它至少会创建与解析器一样多的对象。

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

因此,问题 (1)(用例)的答案是,如果必须处理整个 XML,则使用解析器,如果只处理其中的一部分,则使用解析器。 API 和语法在其中并没有真正发挥多大作用。 Groovy 人试图使这两者在用户体验上非常相似。此外,如果您想对 XML 进行增量更改,您会更喜欢解析器而不是 slurper。

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

问题(3)也可以通过简介来回答。如果您有多个惰性评估路径,则必须再次评估,那么这可能比您仅在解析器中导航现有图形要慢。因此解析器可以更快,具体取决于您的使用情况。

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

至于 (3c)...现在两者都可以更新/转换 XML。哪个更快实际上更多地与您必须更改 xml 的多少部分相关。如果有很多部分我会说解析器,如果不是,那么可能是slurper。但是,如果您想使用 slurper 将属性值从“Fred”更改为“John”,只是为了稍后使用相同的 slurper 查询此“John”,则它将不起作用。

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.

小兔几 2024-12-13 10:59:14

我会给你明确的答案:

  • XML Parser 比 XML Slurper 更快。
  • XML Slurper 比 XML Parser 消耗更少的内存。
  • XML解析器可以同时解析和更新XML。
  • 对于 XML Slurper,您需要在每次更新后标记构建 XML。
  • 当您想使用路径表达式时,XML Slurper 会比解析器更好。
  • 对于读取几乎所有节点,XML 解析器就可以了。

希望有帮助

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文