Si el rendimiento es un factor importante, y/o el tamaño del documento es grande (ambos parecen ser el caso aquí), la diferencia entre un analizador de eventos (como SAX o StAX) y la implementación Java XPath nativa es que este último crea un documento W3C DOM antes de evaluar la expresión XPath. [Es interesante observar que todas las implementaciones de Java Document Object Model como DOM o Axiom usan un procesador de eventos (como SAX o StAX) para construir la representación en memoria, por lo que si alguna vez puede funcionar solo con el procesador de eventos que está guardando tanto la memoria como el tiempo que lleva construir un DOM.]
Como mencioné anteriormente, la implementación de XPath en el JDK opera sobre un documento W3C DOM. Esto se puede ver en la implementación del código fuente de Java JDK examinado com.sun.org.apache.xpath.internal.jaxp.XPathImpl
, donde antes del método de evaluar() se llama el analizador debe primero analizar la fuente:
Document document = getParser().parse(source);
Después de esto su 10GB de XML serán representados en la memoria (más cualquier gasto adicional) — probablemente no sea lo que quiere. Si bien es posible que desee una solución más "genérica", tanto su XPath de ejemplo como su marcado XML parecen relativamente simples, por lo que no parece haber una justificación sólida para una XPath (excepto tal vez programación de elegancia). Lo mismo ocurriría con la sugerencia de XProc: esto también generaría un DOM. Si realmente necesita un DOM, podría usar Axiom en lugar del W3C DOM. Axiom tiene una API mucho más amigable y construye su DOM sobre StAX, por lo que es rápido y utiliza Jaxen para su implementación de XPath. Jaxen requiere algunos tipo de DOM (W3C DOM, DOM4J o JDOM). Esto será cierto para todas las implementaciones de XPath, por lo que si realmente no necesita quedarse con XPath solo se recomienda el analizador de eventos.
SAX es la antigua API de transmisión, con StAX más nuevo y mucho más rápido. Ya sea utilizando la implementación nativa JDK StAX (javax.xml.stream
) o la implementación StAX Woodstox (que es significativamente más rápida, según mi experiencia), recomendaría crear un filtro de eventos XML que coincida primero con el nombre del tipo de elemento (para capturar los elementos <txn>
). Esto creará pequeñas ráfagas de eventos (elemento, atributo, texto) que se pueden verificar para los valores de usuario coincidentes. Con una coincidencia adecuada, puede extraer la información necesaria de los eventos o canalizar los eventos acotados para crear un mini-DOM a partir de ellos si encuentra que el resultado es más fácil de navegar. Pero parece que eso podría ser exagerado si el marcado es simple.
Este sería probablemente el enfoque más simple, más rápido posible y evitaría la sobrecarga de memoria de construir un DOM. Si pasó los nombres del elemento y el atributo al filtro (para que el algoritmo de coincidencia sea configurable) podría hacerlo relativamente genérico.
Mi recomendación es usar extendida ETV-XML en modo de mapa MEM y 64 bit jvm –