rendimiento de marshaller de Java

Question

He utilizado JAXB Marshaller, así como mi propio Marshaller para reunir objetos puros de java en XML. Se ha observado que ambos requieren casi el mismo tiempo para reunir. El rendimiento no es aceptable y debe mejorarse. ¿De qué formas podemos mejorar el rendimiento de Marshaller? ¿Como enhebrar?

Answer 1

Secundando el uso de JibX. Al igual que en Questzen, descubrí que JibX era 9 veces más rápido que JAXB en mis pruebas de rendimiento.

Además, asegúrese de tener woodstox en el classpath cuando use JibX. Descubrí que la implementación de Stax de woodstox es aproximadamente un 1050% más rápida que la implementación de Stax en Java6.

Answer 2

En mi experiencia, JIBX http://jibx.sourceforge.net/ era casi 10 veces más rápido que JAXB. Sí, lo medí para una especificación de rendimiento. Lo usamos para enlazar beans de Java con HL7 xml grande. Dicho esto, la forma de mejorar el rendimiento no es confiar en la definición del esquema sino escribir enlaces personalizados.

Answer 3

Asegúrese de crear la instancia de contexto JaxB solo una vez, ya que la creación del contexto requiere cierto tiempo ya que utiliza la reflexión para analizar las anotaciones del objeto.

Tenga en cuenta que el JAXBContext es seguro para subprocesos, pero los marshallers \ unmarshallers no lo son, por lo que todavía tiene que crear el Marshaller para cada subproceso. Sin embargo, descubrí que crear los Marshallers cuando ya tienes un contexto jaxb es bastante rápido.

Answer 4

Byeond otras buenas sugerencias, sugiero que hay algo mal con el modo de usar JAXB - por lo general es razonablemente bien realizar siempre y cuando:

• Se utiliza JAXB versión 2 (Nunca uses obsoleta JAXB 1 - esa fue una mierda terriblemente lenta, inútil); preferiblemente una versión 2.1.x reciente de http://jaxb.dev.java.net
• Asegúrese de utilizar SAX o fuente/destino Stax; NUNCA use DOM a menos que sea imprescindible para la interoperabilidad: usar DOM lo hará 3 - 5 veces más lento, sin ningún beneficio (solo duplica el modelo de objeto: POJO -> DOM -> XML; la parte DOM es completamente innecesaria)
• Idealmente use el más rápido Analizador SAX/Stax disponible; Woodstox es más rápido que el procesador Stax paquete de Sun (y ref. Impl de BEA. Está libre de errores, no más rápido de Sun)

Si JAXB sigue siendo más del 50% más lenta que la variante escrita manualmente, me perfil para ver qué lo demás está yendo mal. No debe funcionar despacio cuando se usa de forma adecuada; lo he medido continuamente y lo he encontrado tan rápido que, por lo general, los convertidores de escritura a mano no merecen tiempo ni esfuerzo.

Jibx es un buen paquete también por cierto, así que no tengo nada en contra de probarlo. Todavía podría ser un poco más rápido que JAXB; simplemente no 5x o 10x, cuando ambos se usan correctamente.

Answer 5

Podemos lograr el rendimiento en Marshalling y unmarshalling estableciendo la propiedad de arranque rápido a nivel del sistema. Esto dará mucha mejora en el rendimiento.

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

Answer 6

Acabamos de rastrear un problema de rendimiento JAXB relacionado con la configuración de analizador predeterminada utilizada por Xerces. El rendimiento JAXB fue muy lento (30s +) para un archivo de datos (< 1Mb)

Citando "¿Cómo cambio la configuración predeterminada del analizador?"De http://xerces.apache.org/xerces2-j/faq-xni.html

Los analizadores DOM y SAX decidir qué configuración analizador a utilizar en el siguiente orden

1. la propiedad del sistema org.apache.xerces.xni.parser.XMLParserConfiguration se consulta para el nombre de clase de la configuración del analizador
2. Si existe un archivo llamado xerces.properties en el subdirectorio lib de la instalación de JRE y se define la propiedad org.apache.xerces.xni.parser.XMLParserConfiguration, su valor se leerá desde archivo
3. El archivo org.apache.xerces.xni.parser.XMLParserConfiguration se solicita del directorio META-INF/services /. Este archivo contiene el nombre de clase de la configuración del analizador.
4. La configuración org.apache.xerces.parsers.XIncludeAwareParserConfiguration se utiliza como la configuración predeterminada del analizador.

unmarshalling utilizando los resultados JAXB en este algoritmo que se aplica repetidamente. Por lo tanto, se puede dedicar una gran cantidad de tiempo a explorar repetidamente el classpath, buscando el archivo de configuración que no existe. La solución es hacer la opción 1, la opción 2 o la opción 3 (crear el archivo de configuración bajo META-INF). Cualquier cosa para evitar el escaneo repetido del classpath.

Espero que esto ayude a alguien, nos ha llevado días rastrear esto.

Answer 7

Si grandes árboles XML están escritos, proporcionando una BufferedOutputStream al método javax.xml.bind.Marshaller.marshal(Object jaxbElement, java.io.OutputStream os) hecho una gran diferencia en mi caso:

El tiempo necesario para escribir un archivo XML 100MB podría reducirse de 130 segundos a 7 segundos.