Comparación de las Tecnologías Java para XML

La página anterior nos ofreció una introducción al API Java para Procesar XML (JAXP), y las tecnologías que directa o indirectamente proporcionan al desarrollador Java las tecnologías para poder procesar documentos XML. Ilustró el uso de los diferentes APIs con algunos programas de ejemplo. Esta segunda página se centra en el rendimiento relativo de estos APIs obtenidos ejecutando los programas de ejemplo presentados en la primera página. Este tutorial concluye con una tecera página en que ofreceremos trucos para mejorar el rendimiento de las aplicaciones basadas en XML desde un punto de vista programático y arquitectural.

El propósito de las pruebas presentadas en esta página es principalmente ilustrar el rendimiento respectivo de las diferentes técnicas de procesamiento XML: SAX, DOM, XSLT, y el impacto de la valicación contra un DTD o contra un Esquema XML. También se comparan los rendimientos de las diferentes implementaciones del API: Xerces, Crimson, Xalan, Saxon, XSLTC, etc. cuando se ejecutan en diferentes entornos de ejecución Java JDK 1.2 y JDK 1.3 . Los resultados presentados aquí no pretenden cubrir todas las implementaciones del API disponibles hoy en día sino subrayar que la diferencia entre la facilidad de uso y el rendimiento de los modelos de procesamiento elegidos puede evitarse mediante la implementación de un analizador, un constructor de documento o un motor de hoja de estilo subyacentes.

. Metodología

Los programas de ejemplo presentados en la página anterior demostraban el uso de los diferentes APIs disponibles. Para poder ser comparados, los hemos aplicado para resolver el mismo problema, y proporcionar idéntica solución. El problema se mantuvo simple para acomodar las diferentes capacidades de estas tecnologias y por lo tanto podría no tener la riqueza y potencia relevantes de otros más sofisticados como XSLT y XPath. En este respecto, las pruebas de rendimiento presentadas como micro-comparaciones.

Los programas de ejemplo estaban basados en los diferentes APIs para procesamiento de XML,

  • SAX, Simple API for XML
  • DOM, Document Object Model API from W3C
  • XSLT, XML Style Sheet Language Transformations from W3C
  • XPath, XML Path Language from W3C
  • JDOM, "Java optimized" document object model API from jdom.org

aplicados al mismo conjunto de documentos para proporcioar exactamente la misma salida. Los documentos XML procesados usando estas técnicas diferentes están conforme a la misma Document Type Definition o XML Schema. Estos esquemas especifican la representación de un conjunto de configuraciones de tableros de ajedrez:

Ilustración 2.1: Una Configuración de Tablero de Ajedrez.

En los esquemas, el número de configuraciones de tableros es ilimitado, permitiendo que se defina cualquier número de configuraciones dentro de un sólo documento. Para poder medir el rendimiento de los diferentes programas de ejemplo, se han creado documentos con 10, 100, 200, 300, 400, 500, 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez.

Los documentos XML conformes al Chessboards.dtd y al esquema Chessboards.xsd tienen idéntica estructura y contenido, la única excepción es reemplazar la Declaración de Tipo de Documento por una referencia al Esquema XML. Para la prueba que implica a los esquemas XML, sólo se usó un documento con 100 configuraciones de tableros de ajedrez.

Código de ejemplo 1: Un documento XML conforme a la DTD (Chessboards-[10-5000].xml)

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE CHESSBOARDS SYSTEM "dtd/Chessboards.dtd">

<CHESSBOARDS>
 <CHESSBOARD>
  <WHITEPIECES>
   <KING><POSITION COLUMN="G" ROW="1" /></KING>
   <BISHOP><POSITION COLUMN="D" ROW="6" /></BISHOP>
   <ROOK><POSITION COLUMN="E" ROW="1" /></ROOK>
   <PAWN><POSITION COLUMN="A" ROW="4" /></PAWN>
   <PAWN><POSITION COLUMN="B" ROW="3" /></PAWN>
   <PAWN><POSITION COLUMN="C" ROW="2" /></PAWN>
   <PAWN><POSITION COLUMN="F" ROW="2" /></PAWN>
   <PAWN><POSITION COLUMN="G" ROW="2" /></PAWN>
   <PAWN><POSITION COLUMN="H" ROW="5" /></PAWN>
  </WHITEPIECES>
  <BLACKPIECES>
   <KING><POSITION COLUMN="B" ROW="6" /></KING>
   <QUEEN><POSITION COLUMN="A" ROW="7" /></QUEEN>
   <PAWN><POSITION COLUMN="A" ROW="5" /></PAWN>
   <PAWN><POSITION COLUMN="D" ROW="4" /></PAWN>
  </BLACKPIECES>
 </CHESSBOARD>
 <CHESSBOARD>
  ...
 </CHESSBOARD>
</CHESSBOARDS>

Las diferentes implementaciones basadas en SAX, DOM, XSLT, XPath, etc, cuando se aplican sobre los mismos documentos de entrada, proporcionan la misma salida: una representación en formato de texto de una configuración de tablero de ajedrez.

Código de Ejemplo 2: Una representación en formato de texto de una configuración de tablero de ajedrez:

White king: G1
White bishop: D6
White rook: E1
White pawn: A4
White pawn: B3
White pawn: C2
White pawn: F2
White pawn: G2
White pawn: H5
Black king: B6
Black queen: A7
Black pawn: A5
Black pawn: D4

Todos los programas de ejemplo usan el API Java para Procesar XML (JAXP) para interactuar con las diferentes implementaciones subyacentes de los analizadores SAX, los constructores de documentos DOM y los motores de Transformación XSL, y comparten una estructura común que pemite comparar sus respectivos rendimientos. Permiten el paso típico de usar JAXP, y adicionalmente incluyen dos bucles para procesar el mismo documento varias veces y en varias ejecuciones. Por cada ejecución, se usa una factoría para crear un analizador, una procesador de hoja de estilo, etc, que a su vez son usados para procesar un documento fuente XML varias veces. La validación del documento fuente contra sus DTDs o Esquemas XML declarados podría ser especificada cuando se llama al programa y está implementada configurando la factoría a través de su método setValidating que crea un analizador con o sin validación.

En el código de ejemplo (ChessboardSAXPrinter.java) de abajo, después de ejecutarse se saca el tiempo medio tardado en procesar un documento. Los tiempos del sistema y del usuario podrían medirse lanzando la Máquina Virtual Java (JVM) con el comando ptime.

Código de Ejemplo 3: Ejemplo de la estructura común de los programas de ejemplo (ChessboardSAXPrinter.java)

import org.xml.sax.*;
import org.xml.sax.helpers.*;
import javax.xml.parsers.*;

public class ChessboardSAXPrinter {
 private SAXParser parser;

 public ChessboardSAXPrinter(boolean validating)
   throws Exception {
  SAXParserFactory factory 
    = SAXParserFactory.newInstance();
  factory.setValidating(validating);
  parser = factory.newSAXParser();
  ...
  return;
 }

 public void print(String fileName, PrintStream out)
   throws SAXException, IOException {
  ...
  parser.parse(fileName, ...);
  return;
 }
  
 public static void main(String[] args) {
  ...   
  for (int k = 0; k < r; k++) {
    // r: number of runs
   ChessboardSAXPrinter saxPrinter
     = new ChessboardSAXPrinter(validating);
   long time = System.currentTimeMillis();
   for (int i = 0; i < n; i++) {
     // n: number of document processed per run
    saxPrinter.print(args[0], out);
   }
   // print out the average time (s) 
   // to process a document during the current run
   System.err.print( 
     (((double) (System.currentTimeMillis()
     - time)) / 1000 / n) + "\t");
  }
  ...
 }
}

Dependiendo del rendimiento probado, se realizan dos medidas diferentes:

  • El tiempo medio tardado en procesar el documento, medido entre cada ejecución del propio programa con dos llamadas al método System currentTimeMillis. Sólo las últimas ejecuciones podrían ser tenidas en cuenta para esta medida permitiendo que todas las clases sean cargadas en la Máquina Virtual para compilar y optimizar los byte codes antes de empezar la medida. Esta medida se utiliza normalmente para ilustrar las diferencias entre las Máquinas Virtuales y especialmente la mejora de optimización sobre el tiempo. Esta medida es senbile a factores externos, especialmente con la actividad del sistema no ralacionada con la prueba.
  • La media del tiempo de sistema+usuario para procesar un documento, setá basada en la salida del comando ptime. La suma de los tiempos del sistema y del usuario para completar la ejecución incluyendo la arrancada de la Máquina Virtual es medida y promediada por cada documento procesado. Esta medida es más fiable y se convierte en significante cuando el tiempo de arrancada es mínimo comparado con la carga de trabajo preparada.

El fragmento de código de un makefile (abajo) muestra que el programa fuente perf1 ChessboardSAXPrinter será ejecutado para todos los documentos fuente (../samples/Chessboards-{10, 100, 1000, 2000, 3000, 4000, 5000}.xml) según se especifica en la variable SAMPLING y cada uno de esos documentos será procesado 10 veces (variable PROCESSINGS) por cada 10 ejecuciones (variable RUNS). Los tiempos de sistema y de usaurio serán medidos por el comando ptime y apropiadamente promediados y formateados por un script awk (variable FORMATTER). La variable OPTIONS permite pasar las propiedades seleccionadas a las implementaciones del analizador SAX, del constructor DOM o del motor XSLT para ser usadas. La propiedad XML.validation la usa el propio programa de ejemplo para activar o desactivar la validación. La salida del program se redirige a /dev/null para minimizar el impacto de la I/O de disco en los resultados de rendimiento.

Código de Ejemplo 4: fragmento de código de un makefile

SAMPLING=10 100 1000 2000 3000 4000 5000
MAXTIME=3000
RUNS=10
PROCESSINGS=10
TIMER=ptime

OPTIONS= \
  -Djavax.xml.parsers.SAXParserFactory=\
     org.apache.xerces.jaxp.SAXParserFactoryImpl \
  -Djavax.xml.parsers.DocumentBuilderFactory=\
     org.apache.xerces.jaxp.DocumentBuilderFactoryImpl \  
  -Djavax.xml.transformer.TransformerFactory=\
     org.apache.xalan.processor.TransformerFactoryImpl 

FORMATTER= \
  /usr/xpg4/bin/awk -v runs=$${RUNS:=$(RUNS)} \
    -v processings=$${PROCESSINGS:=$(PROCESSINGS)} ' \
BEGIN { \
  count=0; m=split("1:60:3600", f, ":"); \
} { \
  if ($$1=="sys" || $$1=="user") { \
    n=split($$2, a, ":"); \
    for (i = 1; i <= n; i++) { \
count += a[n - i + 1] * f[i]; \
    } \
  } \
} END { 
  printf ":%.4f", count / runs / processings; \
  if (count > $(MAXTIME)) exit 1; \
}'

perf1:
  echo "SAX/Validating (Xerces)\t\c"; \
    for i in $(SAMPLING); \
    do
$(TIMER) $(JAVA) -DXML.validation=true -Xms128m \
  -Xmx128m -classpath $(CLASSPATH) $(OPTIONS) 
  ChessboardSAXPrinter ../samples/Chessboards-$$i.xml 
  /dev/null $(PROCESSINGS) $(RUNS) 2>&1 \
| tee -a $(LOGS) \
| $(FORMATTER) || break; \
    done; \
    echo

Para seleccionar la implementación del analizador SAXL, del constructor DOM o del motor XSLT a probar, se pasan las siguientes propiedades JAXP a la JVM (variable OPTIONS en el ejemplo de arriba):

API Propiedad Valor Implementación
SAX javax.xml.parsers.
SAXParserFactory
org.apache.crimson.jaxp.
SAXParserFactoryImpl
Crimson
SAX javax.xml.parsers.
SAXParserFactory
org.apache.xerces.jaxp.
SAXParserFactoryImpl
Xerces
DOM javax.xml.parsers.
DocumentBuilderFactory
org.apache.crimson.jaxp.
DocumentBuilderFactoryImpl
Crimson
DOM javax.xml.parsers.
DocumentBuilderFactory
org.apache.xerces.jaxp.
DocumentBuilderFactoryImpl
Xerces
XSLT javax.xml.transformer.
TransformerFactory
org.apache.xalan.processor.
TransformerFactoryImpl
Xalan
XSLT javax.xml.transformer.
TransformerFactory
com.icl.saxon.
TransformerFactoryImpl
Saxon
XSLT javax.xml.transformer.
TransformerFactory
org.apache.xalan.
xsltc.runtime.
TransformerFactoryImpl
Xalan-XSLTC

. Configuración

Cada programa de ejemplo se ha probado en diferentes configuraciones: con diferentes tamaños de documentos procesados conformes a sus DTD o a un esquema XML, con o sin validación, con diferentes implementaciones de analizador o motor de hoja de estilo, y con diferentes versiones de la JVM

Productos y Versiones
WorkStation Solaris Operating Environment (SPARC Platform Edition), Ultra-30
Java Runtimes JDK1.2.2_06, JDK1.3.1
Analizadores XML,
Motores XSLT
Xerces 1.3.1 y 1.4.4 (para XML Schemas)
Crimson 1.1 (incluido en JAXP 1.1)
Xalan-Java 2.1 (incluyendo XSLTC)
Saxon 6.3
JAXP 1.1
JDOM beta6
Programas de Ejemplo/APIs ChessboardSAXPrinter.java - SAX
ChessboardDOMPrinter.java - DOM
XSLTTransformation.java y ChessboardPrinter.xsl - XSLT
ChessboardXPathPrinter.java - XPath
ChessboardJDOMPrinter.java - JDOM

. Medidas de Rendimiento

. Comparar Rendimientos de SAX, DOM y XSLT

Esta prueba compara los rendimientos de SAX, DOM y XSLT cuando se aplican para procesar los documentos XML definidos anteriomente. Se han usado dos implementaciones de SAX y DOM: Xerces y Crimson.

Esta prueba midió el tiempo para procesar documentos que describen 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez. Cada documento ha sido procesado 10 veces en 10 ejecuciones. El tiempo medido fue sumado al tiempo del sistema y de usuario, y devuelto por el comando ptime, dividido por el número total de documentos procesados.


Ilustración 2: tiempo para procesar diferentes tamaños de documentos XML usando SAX, DOM y XSLT con Crimson y Xerces (JDK 1.2)

Análisis

Podemos hacer tres observaciones a partir de estas medidas:

  1. Como esperabamos, la clasificación, del más rápido al más lento, es: SAX, DOM, y XSLT. Esto puede explicarse por el hecho de que típicamente un motor XSLT tiene que compilar la hoja de estilo y luego construir internamente el árbol de salida antes de empezar las transformaciones. Podría usar un constructor DOM para hacer esto. El propio constructor DOM podría usar un analizador SAX para analizar tanto el documento de entrada como la hoja de estilo. Si juntamos estás téncicas, añaden más funcionalidad, facilidad de uso y de mentenimiento, pero penalizan más el rendimiento.
  2. Crimson rinde mejor que Xerces. Crimson es una implementación correcta de un analizador XML y tiene un pequeño tamaño 200KB (su tamaño de fichero jar) mientras que Xerces es más sofisticado e incluye muchas características adicionales como soporte de Esquemas XML. Xerces también viene con soporte DOMs de WML y HTML lo que incrementa significativamente el tamaño de su fichero jar hasta 1.5MB. La organización Apache está re-construyendo Xerces y mejorando en el rendimiento en Xerces2.
  3. El tiempo de proceso de un documento se incrementa linearmente con el tamaño del documento. La linearidad del rendimiento demuestra que el test no expuso al máximo ningún recurso del sistema, especialmente la memoria. Teniendo en cuenta esta lineraridad, para la mayoría de los siguientes gráficos sólo presentaremos los resultados de procesar el documento 1000-Chessboard XML de esta forma:

Ilustración 3: Tiempo para procesar documentos XML 1000-Chessboard XML usando SAX, DOM y XSLT con Crimson y Xerces (JDK 1.2)

. Comparar los Rendimientos de XSLT y XSLTC

Esta segunda prueba compara el rendimiento de motores XSLT normales y del motor XSLTC que compila las hojas de estilo en byte codes Java. XSLTC es ahora parte de Xalan y puede invocarse a través del JAXP. No se necesitaron modificaciones en el programa de ejemplo para usar XSLTC.

Esta prueba midió el tiempo para procesar documentos que describen 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez (aunque aquí sólo presentemos el resultado de los documentos de 1000 configuraciones). Cada documento ha sido procesado 10 veces en 10 ejecuciones. El tiempo medido fue sumado al tiempo del sistema y de usuario, y devuelto por el comando ptime, dividido por el número total de documentos procesados.

Medidas


Ilustración 4: Tiempo de procesar documentos XML de 1000-Chessboard usando XSLT y XSLTC (JDK 1.2)

Análisis

Esta prueba mostró que Xalan y Saxon rinden prácticamente lo mismo y que compilar las hojas de estilo en byte codes Java podría mejorar el rendimiento hasta en un 40% cuando se compara con las implementaciones clásicas como Xalan o Saxon sobre Crimson. Comparándolo con las pruebas anteriores, las hojas de estilo compiladas podrían dar mejor rendimiento que DOM y muy cercano a SAX

. Comparar Rendimiento con Validación y sin Validación

Ahora comparamos los rendimientos de SAX y DOM con y sin validación. Usando las implementaciones SAX y DOM de Crimson y Xerces. Lo que se pretende aquí es medir el impacto de la validación en el tiempo de proceso. Para las especificaciones XML, un analizador sin validación no se requiere que lea las entidades externas (incluyendo una DTD externa); por lo tanto las entidades externas referenciadas en el documento podrían no ser expandidas y los atributos podrían no tener sustituidos sus valores por defecto. Así, la información pasada a la aplicación llamante podría no ser equivalente cuando se usa un analizador con o sin validación. En el contexto de este documento, sólo consideramos los analizadores que incluso cuando son sin validación, cargan y analizan la DTD y las entidades referenciadas en el documento. Este permite, por ejemplo, que las entidades sean susituidas, que los valores de atributos sean normalizados y sus valores por defecto apropiadamente sustituidos, por eso que la aplicación se puede ejecutar sin ningun cambio cuando cambiamos de validación a sin validación el documento de entrada.

Esta prueba midió el tiempo para procesar documentos que describen 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez (aunque aquí sólo presentemos el resultado de los documentos de 1000 configuraciones). Cada documento ha sido procesado 10 veces en 10 ejecuciones. El tiempo medido fue sumado al tiempo del sistema y de usuario, y devuelto por el comando ptime, dividido por el número total de documentos procesados.

Medidas


ILustración 5: Tiempo para procesar un documento XML de 1000 configuraciones de tablero de ajedrez usando las implementaciones de DOM y SAX de Crimson y Xerces con y sin validación.

Análisis

SAX rinde mejor que DOM y la validación de los documentos XML de entrada contra sus DTDs incurre en una sobrecarga de hasta el 12% en el caso de la implementación SAX de Xerces. Con la excepción de la implementación SAX de Xerces, el coste de la validación es independiente del API utilizado. La validación se realiza internamente en el analizador. Si un constructor DOM se implementa sobre un analizador DocumentHandler personalizado (ContentHandler en SAX 2), entonces la diferencia entre DOM y SAX se puede tener en cuenta para la construcción del árbol DOM desde los eventos SAX disparados por el analizador.

. Comparar Rendimientos de APIs Alternativos (JDOM, Xpath, YAXA)

Esta prueba compara los rendimientos de DOM con JDOM y XPath. El programa de ejemplo JDOM usa un SAXBuilder para analizar el documento fuente XML en memoria. Pasa a través del documento JDOM resultante y saca el resultado en formato texto. El programa de ejemplo XPath usa el API DOM para analizar y cargar un documento XML en memoria. Luego evalúa expresiones XPath para localizar elementos a ser procesados y saca el resultado en formato texto.

Adicionalmente, esta prueba compara YAXA con SAX y DOM. YAXA es un API experimental que funciona sobre SAX y anade el clásico paradigma Java Event/Source/Listener. El programa de ejemplo YAXA usa un DefaultHandler de SAX2 personalizado para registrar oyentes de eventos que capturan los eventos disparados por el analizador SAX subyacente. YAXA también proprociona un editor de streams de eventos basado en el modelo anterior que edita directamente el flujo de eventos disparado por el analizador SAX. El programa de ejemplo YAXA-SE usa este editor de streams para aplicar un script de edición al flujo de eventos y genera la misma salida que los otros proramas. El editor de streams de eventos estaba inspirado en el comando sed de UNIX.

Esta prueba midió el tiempo para procesar documentos que describen 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez (aunque aquí sólo presentemos el resultado de los documentos de 1000 configuraciones). Cada documento ha sido procesado 10 veces en 60 ejecuciones. El tiempo medido fue sumado al tiempo del sistema y de usuario, y devuelto por el comando ptime, dividido por el número total de documentos procesados.

Medidas


Ilustración 6: Tiempo para procesar un documento XML con 1000 configuraciones de tableros de ajedrez con DOM, JDOM y XPath, usando Crimson y Xerces con validación (JDK 1.2)


Ilustración 7: Tiempo para procesar un documento XML con 1000 configuraciones de tableros de ajedrez con SAX, DOM, YAXA y YAXA-SE (editor de streams de eventos), usando Crimson con validación (JDK 1.2)

Análisis

JDOM es ligeramente más rápido que DOM (alrededor de un 10%) usando la misma implementación de analizador subyacente. Por otro lado XPath rinde de forma casi idéntica, independientemente de la implementación del analizador subyacente. Esto es debido al hecho de que la mayoría del tiempo se va en localizar los elementos relevantes para ser procesados con la expresiones XPath. Como hemos usado la misma implementación de XPath (de Xalan), el tiempo de proceso total es el mismo.

El rendimiento de YAXA es un poco mejor que el de DOM. Como los elementos a procesar constituyen el 90% de todo el documento, termina la creación de eventos de la misma forma que DOM crea objetos nodo. También sigue la pista del contexto actual con una pila que es casi equivalente a construiir el árbol de modelo del documento. Por otro lado, con un simple pero comparable (en el ejemplo dado) mecanismo de correspondencia de patrón, YAXA y el editor de streams de YAXA rinden mejor que XPath y XSLT para esta tarea sencilla.

. Comparar Diferentes Versiones de la JVM

Esta prueba compara el rendimiento de tres diferentes implementaciones/configuraciones del entorno de ejecución Java, JDK 1.2, JDK 1.3 servidor, y JDK 1.3 cliente. Se usaron para procesar los documentos XML definidos anteriormente con dos diferentes implementaciones de SAX y DOM (Xerces y Crimson).

Esta prueba midió el tiempo para procesar documentos que describen 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez (aunque aquí sólo presentemos el resultado de los documentos de 1000 configuraciones). Cada documento ha sido procesado 10 veces en 60 ejecuciones. El tiempo medido fue sumado al tiempo del sistema y de usuario, y devuelto por el comando ptime, dividido por el número total de documentos procesados.

Medidas


Ilustración 8: Tiempo para procesar un documento XML con 1000 configuraciones de tableros de ajedrez usando SAX, DOM, con Crimson y Xerces sobre JDK 1.2, JDK 1.3 Client, y JDK 1.3 Server.


Ilustración 9: El entorno de ejecución JDK 1.3 Server mejoró sobre las 60 ejecuciones del programa de ejemplo DOM sobre Xerces. Una sensible optimización se realizó al final de la prueba que no pudo mostarse en el gráfico anterior

Análisis

Los entornos JDK 1.2 y JDK 1.3 Client rinden de forma similar. Con la excepción del programa DOM que usa Xerces, el entorno JDK 1.3 Server es capaz de mejorar el rendimiento de JDK 1.2 entre un 33 y un 38%. Por otro lado, para los programas de ejemplo DOM usando Xerces, el rendimiento bajó un 5%, pero como se ve en la curva, al final del periodo de ejecución el entorno JDK 1.3 Server fue capaz de optrimizarlo y ganar un 17% (de 6 a 5).

. Comparar el Rendimiento de los Métodos de Acceso DOM

El API DOM ofrece diferentes métodos para acceder a un enlemento de un documento de entrada:

  1. Por nombre (usando getElementsByTagName), todos los elementos con un nombre de etiqueta dado serán devueltos en el orden en que sean encontrados en un orden prévio desde el nodo documento o elemento actual.
  2. Bajando por la estructura del árbol (usando getChildNodes), se devolveran todos los hijos inmediatos del nodo documento o elemento actual.

El primer método es más costoso porque se tiene que atravesar totalmente el sub-arbol por cada llamada al método getElementsByTagName, poro podría requerir menos conocimiento de la estructura del árbol ya que se hace una búsqueda exhaustiva. La búsqueda de diferentes nombres de elementos podría requerir atravesar el árbol varias veces. El segundo método es menos costoso porque el atravesamiento del árbol está controlado: sólo las partes relevantes del sub-árbol podrían ser atravesadas y podría serlo sólo una vez; pero por otro lado, requiere un conocimiento más profundo de la estructura del documento.

Hasta ahora, las pruebas DOM sólo utilizaron el segundo método. Esta prubea mide la diferencia entre estas dos implementaciones de DOM.


Ilustración 10: Tiempo para procesar diferentes tamaños de documentos XML usando diferentes métodos del API DOM y diferentes implementaciones (JDK 1.2)

Análisis

Como esperabamos, el método que trata con el método getElementsByTagName es más lento que los otros. Pero dependiendo de la implementación (específicamente la implementación del algoritmo que pasa a través del árbol), la diferencia podría ser pequeña (Xerces) o dramáticamente mayor/explosiva (Crimson).

. Comparar el Rendimiento de la Validación de DTD y de Esquema XML

Esta prueba compara el rendimiento de las validaciones contra DTDs y Esquemas XML. Usa la implementación SAX de Xerces (la única de las dos implementaciones que soporta Esquemas XML).

Esta prueba midió el tiempo para procesar documentos que describen 1000, 2000, 3000, 4000 y 5000 configuraciones de tableros de ajedrez (aunque aquí sólo presentemos el resultado de los documentos de 1000 configuraciones). Cada documento ha sido procesado 10 veces en 10 ejecuciones. El tiempo medido fue sumado al tiempo del sistema y de usuario, y devuelto por el comando ptime, dividido por el número total de documentos procesados.

Medidas


Ilustración 11: Tiempo para procesar un documento XML con 1000 configuraciones de tableros de ajedrez usando la implementación SAX de Xerces con validación contra un DTD y un esquema XML (usando Xerces 1.4.4).

Análisis

Con Xerces, la validación contra un Esquema XML es más costosa que contra un DTD equivalente. Cuando no se realiza validación, usar un Esquema XML parece ser más rápido que usar el DTD. Esto es debido al hecho de que en esta implementación particular de Xerces (1.4.4), el esquema XML referenciado en el documento de entrada ni siquiera es leído (como hemos revelado monitorizando las llamadas al método EntityResolver). El ejemplar del documento del Esquema XML es por lo tanto tratado como un documento sin DTD (ya que no hay incluso una Declaración de Tipo de Documento - DOCTYPE).

Cuando se ejecuta la comparación con una versión más reciente de Xerces (2.0b4), cuando no se realiza validación, usar el esquema XML es más lento que usar la DTD, casi haciendo la imagen inversa de los resultados obtenidos cuando se valida. En este ejemplar particular, la monitorización de las llamadas a EntityResolver mostró que el Esquema XML era cargado y analizado efectivamente. Incidentalmente, también observamos una sensible mejora del rendimiento con esta nueva versión de Xerces.


Ilustración 12: Tiempo para procesar un documento XML con 1000 configuraciones de tableros de ajedrez usando la implementación SAX de Xerces con validación contra un DTD y un esquema XML (usando Xerces 2.0b4).

. Conclusión

En esta página, hemos probado los diferentes programas de ejemplo presentados en la página anterior y hemos analizado sus respectivos rendimientos cuando se ejecutan en diferentes configuraciones: con diferentes tamaños de documentos procesados, conformes a una DTD o a un Esquema XML, con o sin validación, con diferentes implementaciones de analizadores o motores de hojas de estilos subyacentes y con diferentes versiones de la JVM. Teniendo en cuenta los resultados presentados, la siguiente página intentará mostrarnos algunos trucos para mejorar el rendimiento de las aplicaciones basadas en XML desde un punto de vista programático y arquitectural.

COMPARTE ESTE ARTÍCULO

ENVIAR A UN AMIGO
COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN GOOGLE +
ARTÍCULO ANTERIOR

¡SÉ EL PRIMERO EN COMENTAR!
Conéctate o Regístrate para dejar tu comentario.