The performance tradeoff with Xerces2 much better on small documents and Xerces better on larger documents applies even when you're just using the SAX2 parser, so I'd think it's not a transcoding issue. It looks like Xerces2 DOM is already faster than Xerces DOM in general. I look forward to seeing what happens when things settle down and you get a chance to tune Xerces2!
- Dennis
Andy Clark wrote:
Dennis Sosnoski wrote:
I've updated my Java XML document model benchmark results at http://www.sosnoski.com/opensrc/xmlbench/index.html. These show the
Thanks for the updated benchmark results. It's always best to see comparisons between the latest versions of parsers.
issues with Xerces performance on small documents, especially when the deferred node expansion option is enabled (as it is by default).
I expect this kind of result but it would be good to put some note in the Performance FAQ about this. There's a note in there about the deferred DOM but there should be additional text to suggest only using it when the documents are medium to large sized and turn it off for small documents.
The performance tradeoffs between the original Xerces and Xerces2 are interesting, with Xerces generally doing better on longer documents and Xerces2 better on short ones.
Xerces2 definitely has less startup time so that's why it fairs better on smaller documents. I think that the reason Xerces 1.x does better as the document size grows is due to the fact that Xerces 1.x defers transcoding of characters and Xerces2 transcodes everything upfront. We made this choice in the new design to simplify the implementation and ease maintanence and extensibility for the future. However, we haven't done any rigorous performance tuning of Xerces2 yet so there will probably be room for improvement.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
