Understanding the Results

Charts showing XML Parsing Benchmark results

<< Running the Benchmark    XML Parsing Benchmark    Comparing Parsing Methods >>

The following pages contain a few representative charts that show the time spent to do the parsing or the used memory.

Reading the Charts

Each chart has a legend in the upper-left corner explaining the meaning of the colors, labels for each group of bars at the bottom and a column of numbers on the right side containing seconds or megabytes.

Most labels, such as JDK 1.x, Xerces 1.x, SAX, DOM, etc are self-explanatory. JAXP 1.x means the reference implementation of the JAXP 1.x API. The JAXP 1.1 reference implementation is called Crimson. SAXDOMIX means mixed SAX-DOM parsing and SAXDOMIXT means mixed SAX-DOM parsing based on TrAX. Other labels need some explanation: OFF means no validation and no namespaces support, NS means namespaces support and VAL means validation. When the testing is done with the old SAX 1.0 and DOM Level 1 versions, the label starts with OLD. The omission of OLD means that SAX 2.0 and DOM Level 2 are used.

Multithreading

The charts from the following pages show the results of the single-thread parsing, but the observations remain true in a multi-thread environment. For example, Xerces is very good at DOM parsing while Crimson is better at SAX parsing.

On a single CPU machine, parsing a table of 500 records in 100 concurrent threads will be slower than parsing a table of 50000 records in a single thread due to the context switches that must be performed in the multithreading case. If the server has multiple processors, however, the load is distributed.

We didn't include the results of the multithreading tests because they tend to vary from one run to another probably because the context switches occur in different points. The Java threads are mapped on native threads, which means that the operating system is the one that decides when to perform a context switch. Therefore, the context switches will occur in different points of the executed code. This leads to slightly different performance results from one run to another.

We were surprised to see that sometimes Xerces spends more time parsing the same table with SAX in 80 threads than in 100 threads, for example. This could indicate some synchronization issues within the SAX implementation of Xerces. The Crimson's scalability was very good with all parsing methods.

<< Running the Benchmark    XML Parsing Benchmark    Comparing Parsing Methods >>