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

Question

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

Answer 4

Byeond другие хорошие предложения, я предлагаю что-то не так с тем, как вы используете 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 быстрее, чем комплектный процессор Stax Солнца (и исй. Осущий БЭ. Не глючит, не быстрее, чем Солнца)

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

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

Answer 5

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

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

Answer 6

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

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

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

1. Свойство системы org.apache.xerces.xni.parser.XMLParserConfiguration запрашивается для имени класса из конфигурации парсера.
2. Если в подкаталоге lib установки JRE существует файл с именем xerces.properties, и свойство 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 7

Если большие XML дерева написаны, обеспечивая BufferedOutputStream методы javax.xml.bind.Marshaller.marshal(Object jaxbElement, java.io.OutputStream os) сделал большую разницу в моем случае:

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