Hello Christopher, The Jdom approach was a clean-up in the Slide sources. Some parts did use Jdom (already), some did use Dom (which is very slow and memory consuming) some did use strings (with a possibly improper handling of namespaces), etc. We thought about a pluggable solution for the XML processing, but currently decided (for effort reasons) to stay with Jdom. In-house we did some performance tests with Dom, Jdom and Dom4J, which showed that Dom is the slowest, followed by jdom and dom4j, which were very comparable. We wanted to use Jdom for following reasons: Jdom was already in the code (no new dependency) and Jdom will become a Java standard (jsr 102).
Anyway I have the feeling, that most time is consumed in the store level (dealing with DB access) and less time is consumed in the parsing area. In our performance profiling this parsing was totally out of impact scope (we will do such a profiling again after the jdom change). I will let you know the results. There is one known disadvantage of replacing the XMLWriter class against Jdom. If the Jdom tree gets very big, it will be kept in memory until it is serialized to a stream (important for PropFinds with a huge number of results). The solution here will be to handle each resource by a single jdom tree and when the resource is complete serialize it to the stream and release the memory. (still to be done) If we find out, that the performance has significantly decreased we should definitely look at other options. Does that make sense? Best regards, Juergen -----Original Message----- From: Christopher Lenz [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 13.50 PM To: Slide Developers Mailing List Subject: XML parsing performance (Re: cvs commit: jakarta-slide/src/webdav/server/org/apache/slide/webdav/method SearchMethod.java) Am 23.05.2002 07:23:08, schrieb [EMAIL PROTECTED]: >juergen 02/05/22 22:23:08 > > Modified: src/webdav/server/org/apache/slide/webdav/method > SearchMethod.java > Log: > Replaced usage of org.w3c.dom by JDOM. > (ralf) > [...] I've been noticing the recent trend to replace W3C DOM usage by JDOM to parse the DAV request bodies. I think this should be discussed a bit (although of course those who actually *do* stuff can also do the decision ;P). JDOM isn't actually famous for it's performance. It's advantage now and in the past has been the ease of use. The problem is that a WebDAV server should be as efficient as possible when it comes to XML processing. Our XML generation is already as low-level as it can probably get. Our input processing used to be based on DOM, and is now moving to JDOM, both of which are memory-intensive and on the slow side. There's a very interesting article on IBM's developerWorks about the performance of various XML parsing concepts and implementations: http://www-106.ibm.com/developerworks/xml/library/x-injava/index.html Neither JDOM nor Xerces/Crimson-DOM get very good results. Options for better performance seem to be: - Use dom4j: Faster than DOM/JDOM, and offers direct XPath support for document navigation, which I think could be quite useful for hanlding WebDAV requests. - Use SAX2: Naturally quite fast, but to use SAX2 somewhat conveniently, there would need to be helper classes for the various DAV XML elements. It's not quite clear how much overhead such a layer would introduce. - Use XPP: From the article: "XPP is the performance leader in most respects. For middleware-type applications that do not require validation, entities, processing instructions, or comments, XPP looks to be an excellent choice despite its newness." That description fits pretty well to our requirements. The package is small, and has an Apache-style license. I think it would be very interesting to benchmark JDOM, DOM4J and JDOM used in the WebDAV servlet. Don't currently have the time to do this though, just thought I'd share some thoughts on this topic. On the other hand, current WebDAV clients (most prominently MS WebFolders) don't issue all too complex requests (the typical PROPFIND doesn't even have a body, nor a Depth:-header -- ugh). So maybe efficient request body parsing isn't *that* important. Thoughts? -chris _______________________________________________ /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
