Groovy XmlSlurper проти XmlParser


79

Я деякий час шукав цю тему і також знайшов деякі результати, про які я згадую в кінці допису. Чи може хтось допомогти мені точно відповісти на ці три запитання для випадків, перелічених нижче?

  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 ( XmlParser , XmlSlurper ) та сайт groovy добре пояснюють їх ( тут і тут ), але не дуже добре пояснюють вищезазначене питання.

Відповіді:


106

Велика різниця між XmlSlurper та XmlParser полягає в тому, що парсер створить щось подібне до DOM, тоді як Slurper намагається створювати структури лише за необхідності і, отже, використовує шляхи, які ліниво оцінюються. Для користувача обидва можуть виглядати надзвичайно рівними. Різниця полягає в тому, що структура синтаксичного аналізатора оцінюється лише один раз, шляхи осідання можуть бути оцінені за запитом. За запитом тут можна прочитати як "більш ефективну пам'ять, але повільнішу". Зрештою, це залежить від того, скільки шляхів / запитів ви зробите. Якщо ви, наприклад, хочете знати лише значення атрибута в певній частині XML, а потім закінчити з ним, XmlParser все одно буде обробляти все і виконувати ваш запит на квазі DOM. Через те, що буде створено багато об’єктів, витрачається пам’ять і процесор. XmlSlurper не створюватиме об’єкти, тим самим економить пам’ять та центральний процесор.

Обидва можуть виконувати перетворення в документі, але одержувач припускає, що це константа, і, отже, вам доведеться спочатку виписати зміни та створити новий підбирач, щоб прочитати новий xml. Синтаксичний аналізатор дозволяє бачити зміни відразу.

Отже, відповідь на запитання (1), у випадку використання, полягала б у тому, що ви використовуєте синтаксичний аналізатор, якщо вам потрібно обробити цілий XML, а засліплювач - лише його частини. API та синтаксис насправді не грають великої ролі в цьому. Люди Groovy намагаються зробити цих двох дуже схожими за користувацьким досвідом. Крім того, ви віддаєте перевагу синтаксичному аналізатору перед розбійником, якщо хочете внести поступові зміни до XML.

Це вступ вище також пояснює, що є більш ефективним для пам'яті, питання (2). Оскаржувач, якщо ви все одно все не прочитаєте, тоді парсер може, але я не маю фактичних цифр про те, наскільки велика різниця тоді.

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

Тому я б сказав (3а), що саме читання майже всіх вузлів не має великої різниці, оскільки тоді запити є визначальним фактором. Але у випадку (3b), я б сказав, що оскаржувач швидший, якщо вам просто потрібно прочитати кілька вузлів, оскільки йому не доведеться створювати повну структуру в пам'яті, яка сама по собі вже витрачає час і пам'ять.

Що стосується (3c) ... у ці дні обидва можуть оновити / перетворити XML, що швидше, насправді більше пов’язане із тим, скільки частин xml потрібно змінити. Якщо багато частин, я б сказав парсер, якщо ні, то, можливо, шкварка. Але якщо ви хочете, наприклад, змінити значення атрибута з "Фред" на "Джон" за допомогою засобу слюператора, просто щоб пізніше здійснити запит для цього "Джона", використовуючи той самий шлангер, це не буде працювати.


Дивовижне пояснення оновлення щодо нечітки, дякую. Це вирішило мою проблему під час спроби рекурсивного видалення вузлів, коли "порожньо" в засобі, що, звичайно, не буде працювати.
sandos

4

Я дам вам чіткі відповіді:

* Синтаксичний аналізатор XML швидший, ніж XML Slurper.
* XML Slurper споживає менше пам'яті, ніж XML Parser.
* XML-аналізатор може одночасно аналізувати та оновлювати XML.
* Для XML Slurper потрібно розмітити XML після кожного внесеного оновлення.
* Коли ви хочете використовувати Path Expressions, XML Slurper буде кращим за парсер.
* Для читання майже всіх вузлів XML-аналізатор було б добре

Сподіваюся, це допоможе

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.