2010-09-13 9 views
7

Esta pregunta está relacionada de alguna manera con Fastest XML parser for small, simple documents in Java pero con algunos detalles más.libxml2 de java

Estoy trabajando en una aplicación que necesita analizar muchos (10s de millones), pequeños (aproximadamente 300k) documentos xml. La implementación actual usa xerces-j y toma aproximadamente 2.5 ms por documento xml en una máquina de 1.5 GHz. Me gustaría mejorar este rendimiento. Me encontré con este artículo

http://www.xml.com/pub/a/2007/05/16/xml-parser-benchmarks-part-2.html

alegando que libxml2 puede analizar aproximadamente un orden de magnitud más rápido que cualquier analizadores de Java. No estoy seguro de si lo creo, pero me llamó la atención. ¿Alguien ha intentado usar libxml2 desde el jvm? Si es así, ¿es más rápido que el análisis de dom de java (xerces)? Estoy pensando que todavía necesitaría mi estructura java dom, pero supongo que copiar desde una dominación c-estructurada a java-dom no debería llevar mucho tiempo. Debo tener java-dom - sax no me ayudará en este caso.

actualización: Acabo de escribir una prueba para libxml2 y no fue más rápido que xerces ... concedido que mi capacidad de codificación c es extremadamente oxidado.

actualización que amplió la pregunta un poco aquí: why is sax parsing faster than dom parsing ? and how does stax work? y estoy abierto a la posibilidad de zanjas dom.

Gracias

Respuesta

0

En primer lugar, su pregunta no contiene una pregunta. ¿Que quieres saber?

Supongo que estabas usando JNI para convertir el c-dom en un java-dom. No sé si hay números oficiales, pero en mi experiencia, c + JNI a menudo es más lento que hacerlo directamente en Java.

Si realmente desea acelerar su procesamiento, intente deshacerse de la dom (¿por qué la necesita? Tal vez podamos pensar en una solución). Si todos los archivos xml tienen el mismo esquema, use su propio modelo de datos especializado (y un analizador SAX).

Si solo utiliza un subconjunto de xml (es decir, sin espacios de nombres, solo algunos atributos), considere escribir su propio analizador que produzca directamente objetos Java más eficientes (pero no lo recomendaría).

+0

I en negrita y añadió signos de interrogación. En lo que respecta a abandonar DOM - No puedo y no estoy interesado en explicar por qué. – andersonbd1

+0

Gracias por su contribución. Cambié de opinión. Estoy dispuesto a deshacerme de dom si puedo y explicar más sobre lo que estoy haciendo.Creé una nueva pregunta aquí: http://stackoverflow.com/questions/3825206/why-is-sax-parsing-faster-than-dom-parsing-and-how-does-stax-work – andersonbd1

2

En Java, StAX JSR-173 generalmente se considera el enfoque más rápido para analizar XML. Existen múltiples implementaciones de StAX, la implementación de Woodstox generalmente se considera rápida.

Para mejorar el rendimiento, evitaría DOM. ¿Qué estás haciendo con el XML? Si en última instancia, se trata de objetos, debería considerar una solución OXM. El estándar es JAXB JSR-222. JAXB implementaciones tales como MOXy (Soy el plomo tecnología) va incluso permitirá hacer un mapeo parcial de lo que mejorará el rendimiento:

+0

En lo que respecta al zanjeo DOM - No puedo y no estoy interesado en explicar por qué. – andersonbd1

+0

Gracias por su contribución. Cambié de opinión. Estoy dispuesto a deshacerme de dom si puedo y explicar más sobre lo que estoy haciendo. Creé una nueva pregunta aquí: http://stackoverflow.com/questions/3825206/why-is-sax-parsing-faster-than-dom-parsing-and-how-does-stax-work – andersonbd1

Cuestiones relacionadas