Производительность Java marshaller

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

8
java jaxb marshalling multithreading performance

7 ответов

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

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

4

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

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

12

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

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

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

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

5

Если записаны большие деревья XML, то снабубежать BufferedOutputStream javax.XML.связывать.Маршаллер.маршал (объект jaxbElement, java.Ио.OutputStream os) метод сделал большую разницу в моем случае:

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

3

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

1

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

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

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

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

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

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

1

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

0