Hey Juergen, Am 31.05.2002 16:10:20, schrieb "Pill, Juergen" <[EMAIL PROTECTED]>: >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?
Very much. I must admit I didn't know that JDOM was already being used so heavily in both the core (by search?) as well as in the WebDAV layer. I had thought it's only usage was still in the Webdav-Logger package. Parsing performance is probably indeed not critical, while I believe the huge <propfind>-response you mention above is very common (i.e. for a flat directory structure with lots of entries, a PROPFIND without body and unlimited depth will generate a gigantic response). AFAIK we had been streaming that response while it was being constructed, so both memory usage and "responsiveness" should have been better before moving to JDOM. All that being said, I've been playing around with some architectural ideas to abstract out the parsing and generating of WebDAV XML elements, providing different pluggable implementations. Very much in the continuous refactoring stage though, so I have no idea if it'll eventually get into a good enough state. <btw>It has been my opinion for some time now, that a WebDAV-layer abstracted away from Slide would provide a more stable architecture, which would be much better suited for complete unit-tests because of minimal external dependancies </btw> -chris _______________________________________________ /=/ cmlenz at gmx.de -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
