Производительность маршаллера Java

Question

Я использовал JAXB Marshaller, а также свой собственный маршаллер для маршалинга объектов чистого Java-бина в XML. Было замечено, что им обоим требуется почти одинаковое время для маршала. Производительность не приемлема и должна быть улучшена. Каковы возможные пути улучшения производительности маршаллера? Как поток?

Answer 1

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

Обратите внимание, что JAXBContext является потокобезопасным, но маршалеры \ unmarshallers - нет, поэтому вам все равно придется создавать маршаллер для каждого потока. Однако я обнаружил, что создание маршаллеров, когда у вас уже есть контекст jaxb, выполняется довольно быстро.

Answer 2

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

• Вы используете JAXB версии 2 (НИКОГДА не используйте устаревший JAXB 1 - это был ужасно медленный, бесполезный кусок дерьма); предпочтительно последняя версия 2.1.x от http://jaxb.dev.java.net
• Убедитесь, что вы используете SAX или Stax источник / назначение; НИКОГДА не используйте DOM, если только вы абсолютно не обязаны взаимодействовать: использование DOM сделает его в 3-5 раз медленнее, без какой-либо выгоды (это просто удваивает объектную модель: POJO -> DOM -> XML; часть DOM совершенно не нужна)
• Идеально использовать самый быстрый из доступных SAX / Stax парсер; Woodstox работает быстрее, чем встроенный процессор Sun Stax (и ссылка BEA подразумевает ошибки, не быстрее, чем у Sun)

Если JAXB по-прежнему более чем на 50% медленнее, чем вариант, написанный вручную, я бы профилировал его, чтобы увидеть, что еще идет не так. При правильном использовании он не должен работать медленно - я измерял его непрерывно и нашел его настолько быстрым, что преобразователи для рукописного ввода обычно не стоят времени и усилий.

Jibx тоже неплохой пакет, так что я ничего не имею против его опробовать. Это все еще может быть немного быстрее, чем JAXB; только не 5x или 10x, когда оба используются правильно.

Answer 3

Отказ от использования JibX. Как и Questzen, я обнаружил, что JibX был в 9 раз быстрее, чем JAXB в моих тестах производительности.

Кроме того, убедитесь, что у вас есть woodstox на пути к классам при использовании JibX. Я обнаружил, что реализация Stax от Woodstox примерно на 1050% быстрее, чем реализация Stax на Java6.

Answer 4

Если записаны большие деревья XML, предоставляя BufferedOutputStream для javax.xml.

Время, необходимое для записи XML-файла размером 100 МБ, может быть уменьшено со 130 до 7 секунд.

Answer 5

Мы только что обнаружили проблему производительности JAXB, связанную с конфигурацией синтаксического анализатора по умолчанию, используемой Xerces. Производительность JAXB была очень низкой (30 с +) для одного файла данных (<1 МБ) </p>

Цитата "Как изменить конфигурацию парсера по умолчанию?" от http://xerces.apache.org/xerces2-j/faq-xni.html

Парсеры DOM и SAX решают, какую конфигурацию парсера использовать в следующем порядке

1. Системное свойство org.apache.xerces.xni.parser.XMLParserConfiguration запрашивается для имени класса конфигурации синтаксического анализатора.
2. Если файл с именем xerces.properties существует в подкаталоге lib установки JRE и для него определено свойство org.apache.xerces.xni.parser.XMLParserConfiguration, его значение будет считано из файла.
3. Файл org.apache.xerces.xni.parser.XMLParserConfiguration запрашивается из каталога META-INF / services /. Этот файл содержит имя класса конфигурации парсера.
4. org.apache.xerces.parsers.XIncludeAwareParserConfiguration используется в качестве конфигурации синтаксического анализатора по умолчанию.

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

Надеюсь, это кому-то поможет - нам потребовались дни, чтобы выследить это.

Answer 6

По моему опыту, JIBX http://jibx.sourceforge.net/ был почти в 10 раз быстрее JAXB. Да, я измерял это для спецификации производительности. Мы использовали его для связывания Java-бобов с большими XML-кодами HL7. При этом способ повышения производительности заключается не в том, чтобы полагаться на определение схемы, а на написание пользовательских привязок.

Answer 7

Мы можем достичь производительности в Marshalling и unmarshalling, установив свойство быстрой загрузки на системном уровне.Это значительно улучшит производительность.

System.setProperty ("com.sun.xml.bind.v2.runtime.JAXBContextImpl.fastBoot", "true");