Groovy XmlSlurper vs XmlParser - программирование

Я искал какое-то время по этой теме и нашел некоторые результаты тоже, о которых я упоминаю в конце сообщения. Может ли кто-нибудь помочь мне точно ответить на эти три вопроса для перечисленных ниже случаев?

Для каких случаев использование XmlSluper имеет больше смысла, чем XmlParser и наоборот (с точки зрения простоты использования API/синтаксиса)?
Какой из них более эффективен с точки зрения памяти? (выглядит как Slurper)
который быстрее обрабатывает xml?

Случай a. когда мне нужно прочитать почти все узлы в 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 doc (XmlParser, XmlSlurper), а сайт groovy хорошо объясняет их (здесь и здесь), но не делает большой работы в объяснении вышеупомянутого вопроса.

Ответ 1

Большая разница между XmlSlurper и XmlParser заключается в том, что Parser создаст нечто похожее на DOM, в то время как Slurper пытается создать структуры только в случае необходимости и, следовательно, использует пути, которые лениво оцениваются. Для пользователя оба пользователя могут выглядеть очень равными. Разница в том, что структура парсера оценивается только один раз, пути отрывков могут оцениваться по требованию. По требованию можно читать как "более эффективную память, но медленнее" здесь. В конечном счете это зависит от того, сколько путей или запросов вы делаете. Если вы, например, хотите узнать только значение атрибута в определенной части XML, а затем сделать это, XmlParser все равно обработает все и выполнит ваш запрос в квази-DOM. При этом будет создано множество объектов, затраты памяти и процессора. XmlSlurper не будет создавать объекты, таким образом сохраняя память и процессор. Если вам все же нужны все части документа, slurper теряет преимущество, так как он создаст по крайней мере столько же объектов, сколько и синтаксический анализатор.

Оба могут делать преобразования в документе, но slurper предполагает, что он является константой, и поэтому вам придется сначала написать изменения и создать новый slurper для чтения нового xml. Парсер поддерживает видя изменения сразу.

Таким образом, ответ на вопрос (1), пример использования, будет заключаться в том, что вы используете парсер, если вам нужно обработать весь XML, slurper, если только его части. API и синтаксис на самом деле не играют в этом большой роли. Люди Groovy пытаются сделать эти два очень похожими на пользователя. Также вы предпочли бы парсер над slurper, если хотите внести дополнительные изменения в XML.

Это введение выше также объясняет, что более эффективно с памятью, вопрос (2). Убойщик, если вы все равно не читаете, тогда может быть парсер, но у меня нет фактических цифр о том, насколько велика разница.

На вопрос (3) можно ответить на ввод. Если у вас есть несколько ленивых оценочных путей, вам нужно снова просчитать, то это может быть медленнее, чем если вы просто перемещаете существующий график, как в парсере. Таким образом, парсер может быть быстрее, в зависимости от вашего использования.

Итак, я бы сказал, что (3a) чтение почти всех узлов само по себе не имеет большого значения, так как тогда запросы являются более определяющим фактором. Но в случае (3b) я бы сказал, что slurper работает быстрее, если вам просто нужно прочитать несколько узлов, так как ему не нужно создавать полную структуру в памяти, которая сама по себе уже требует времени и памяти.

Что касается (3c)... в эти дни оба могут обновлять/преобразовывать XML, что быстрее на самом деле больше связано с тем, сколько частей xml вам нужно изменить. Если много частей, я бы сказал, что синтаксический анализатор, если нет, то, может быть, разбойник. Но если вы хотите, например, изменить значение атрибута от "Fred" до "John" с помощью slurper, просто для более позднего запроса для этого "John", используя тот же самый slurper, он не будет работать.