Самый быстрый XML-парсер для небольших простых документов в Java

Мне приходится объективировать очень простые и маленькие XML-документы (менее 1k, и это почти SGML: нет пространств имен, простой UTF-8, вы его называете...), читаете из потока, на Java.

Я использую JAXP для обработки данных из моего потока в объект Document. Я пробовал Xerces, он слишком большой и медленный... Я использую Dom4j, но я все еще провожу слишком много времени в org.dom4j.io.SAXReader.

Есть ли у кого-нибудь предложения о более быстрой и эффективной реализации, имея в виду, что у меня очень жесткие ограничения на процессор и память?

[Редактировать 1] Имейте в виду, что мои документы очень маленькие, поэтому накладные расходы на просмотр парсера могут быть важны. Например, я трачу столько времени в org.xml.sax.helpers.XMLReaderFactory.createXMLReader, что и в org.dom4j.io.SAXReader.read

[Редактировать 2] Результат должен быть в формате Dom, поскольку я передаю документ инструментам принятия решений, которые выполняют произвольную обработку на нем, например, переключая код на основе значения произвольных XPaths, а также извлекая списки значений, упакованных как дети предопределенного node.

[Редактировать 3] В любом случае мне в конечном итоге нужно загрузить/разобрать полный документ, так как вся содержащаяся в нем информация будет использоваться в какой-то момент.

(Этот вопрос связан с, но отличается от Лучшим парсером XML для Java)

Ответ 1

Вообще говоря, Xerces будет самым быстрым, что вы найдете. Кроме того, анализатор SAX или анализатор тяги должен давать вам намного лучшую производительность, чем синтаксический анализатор.

Ответ 2

Я бы дал XOM. Он использует парсер SAX и строит на нем компактную древовидную модель. Вы можете сделать это еще быстрее, используя эти советы.

Если вы хотите обрабатывать документ "на лету", вы можете реализовать пользовательский NodeFactory для обработки документа, пока он еще разобран SAX синтаксический анализатор. Это проще, чем пользовательский обработчик SAX, потому что вы можете обрабатывать целые элементы после их анализа. Обработчик SAX должен будет обрабатывать правильные начальные и конечные события.

Если вы разбираете несколько документов, вы можете повторно использовать объект Builder, чтобы сэкономить время.

Ответ 3

Взгляните на VTD-XML - это самый быстрый в мире процессор XML и самый мощный в мире процессор, как говорится на сайте.

Он не поддерживает стандартную DOM, но имеет свои собственные методы для обхода Node и поддерживает XPath. Он поддерживает инкрементные обновления документа.

Он имеет реализации для Java, C и С#.

Он основан на инновационном алгоритме "Виртуальный дескриптор токена".

Ответ 4

Посмотрите на использование StAX (Streaming API для XML) вместо SAX. Это будет проще, чем SAX, но не так тяжело, как синтаксический анализатор на основе дерева.

Ответ 5

Не уверен, что он соответствует всем вашим требованиям, но у меня были очень хорошие результаты с точки зрения как скорости, так и потребления памяти (в документах xml очень больших и очень малых) с Nux.

Один из его пунктов дизайна - для "маршрутизатора приложений", который эффективно обрабатывает множество небольших XML-сообщений. Он предлагает возможность запроса xpath, а также доступ к dom-подобному доступу к родительским, дочерним и родственным узлам (в зависимости от выбранного механизма синтаксического анализа).

Ответ 6

Если вы действительно должны создать дерево DOM, лучше всего использовать Xerces. Это приличный парсер (не самый быстрый, но довольно быстрый). Но с DOM происходит интенсивное использование памяти и нестандартная скорость - чего нельзя избежать. Использование JDom/XOM/Dom4j не имеет смысла, если существует такое ограничение DOM; в противном случае XOM очень хорош. Но в этом случае вы переходите от одной модели дерева к другой и выполняете тяжелую операцию.

Стоит отметить, что нет такого понятия, как парсер DOM: все фактические синтаксические анализаторы xml построены на потоковых API (sax, stax или xmlpull). Вы также можете построить дерево DOM с помощью парсеров stax, но накладные расходы действительно связаны с DOM, а не с парсером. Поэтому просто использовать Xerces + DOM - разумный способ сделать это.

Ответ 7

Посмотрите результаты анализа парсера XML с сайта парсера Piccolo. Я также использовал сам piccolo, и это было лучше всего с точки скорости для моих данных.

Ответ 8

Простой Java XML Parser очень быстро. Я нашел его в 10 раз быстрее, чем XOM. API также очень элегантен.

Причина, по которой она быстрее, заключается в том, что она не создает Объекты, представляющие XML файл (Элементы, Атрибуты и т.д.), как это делает XOM. Скорее это событие основано; вы регистрируете обратные вызовы и называет их, когда обнаруживает определенные теги и атрибуты, которые вы указали.

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

Ответ 9

Если вы хотите быстро, вам нужно скомпилировать DTD или схему в рекурсивный анализатор спуска. Такие синтаксические анализаторы могут быть в 2-3 раза быстрее, чем обычные синтаксические анализаторы, благодаря тому, что они точно знают, какие варианты выбора последуют. Я бы посмотрел на такие инструменты, как XML Thunder (EDIT: oops, это не для Java) или XML Booster

EDIT2: Просто заметил изменение, требующее его совместимости с DOM. Я не думаю, что это так. Но ОП задает имхо для плохой комбинации: малый/быстрый и совместимый с DOM. Выберите один.

Ответ 10

Я нашел Woodstox довольно быстро. Он основан на StAX, поэтому очень похож на SAX.

Помимо производительности Woodstox, StAX также иногда упрощает и более элегантно, чем SAX, прерывать разбор документа, если вам нужны только данные из его части, а не всего, или если вы хотите пропустить некоторые частей. Это может позволить вам написать код вашего обработчика более эффективным образом. Например, SAX необходимо сгенерировать строки для некоторых событий, даже если вы проигнорируете события, а с помощью итераторного подхода StAX вы можете пропустить этот шаг или получить доступ, например. символьные данные из массива char без необходимости создавать строку, если она вам не нужна.

Ответ 11

Обратите внимание, что при использовании Xerces для анализа тысяч небольших документов повторное использование анализатора имеет большое значение по сравнению с созданием нового парсера каждый раз.