A raster version of this image is available for those without SVG display capabilities. As an aside, users of SVG renderers supporting the <script> tag should note that the bars, on mouse over, highlight, error bars appear and data values are displayed. Additionally, the resource names in blue at the bottom of the graph are linked to the tabulator's interface for browsing. If your SVG renderer is not <script> capable, you should see the bar graph with all error bars and data values.
The files used to bench the parsers were arbitrarily chosen as 'real world' examples.
Each file was parsed 25 times to achieve a relatively small standard error. The benchmarking was done in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060608 Ubuntu/dapper-security Firefox/1.5.0.4 on a cleanly booted, idle IBM Thinkpad R52 laptop with 512MB of memory and a 1.83GHz processor. The DOM was cloned for each run and each parser was run on its own to avoid interaction with the other.
As you can see, the new parser performs comparably but worse on four of the five 'real world' test cases. This is somewhat misleading, however, because the parser's speed is highly dependent on the serialization of the RDF into XML. If we construct test cases with compact RDF/XML serialization, we find that the old parser is no contest for RDFParser. With these test cases, however, the old parser also does not return all the serialized triples as it does not support the compact serialization shortcuts in the RDF/XML specification. For example, this file parses at 1.33 +/- 0.03 ms/triple in RDFParser but only 1.88 +/- 0.04 ms/triple in the old parser. The old parser also does not return all the triples. The file contains 18 triples but the old parser returns only 15 (the speed per triple was calculating as if both parsers had returned 18 triples).
