[
https://issues.apache.org/jira/browse/JCR-1312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559414#action_12559414
]
Ian Boston commented on JCR-1312:
---------------------------------
Also agree.... and have some more recent evidence.
The benefits of SAX over DOM only become apparent when the DOM tree being
created is large enough and hangs arround long enough to get out of the Eden
GC.... if it does and the server is under extrem load, the GC processes will
start to dominate and cause performance problems both on memory, and because of
memory cpu. Although xpp is lightning fast and has much lower memory
requirements than the parser used for both dom and sax, the cost of refactoring
may well be excessive.
When we rewrote the processing pipelines of a application (sakai) with lots of
DOM processing, we also gathered the evidence through detailed profiling before
doing anything. It was quite hard to get significant gains under load for
fragments of <100 elements that hang around for less than 200ms, is most
request cycles.
> Get rid of DOM for XML support
> ------------------------------
>
> Key: JCR-1312
> URL: https://issues.apache.org/jira/browse/JCR-1312
> Project: Jackrabbit
> Issue Type: Improvement
> Components: jackrabbit-webdav
> Reporter: Felix Meschberger
>
> Currently the web dav library uses Xerces and DOM to parse and create XML
> data. This mechanism is well-known but has two major issues: It is slow and
> it has a big memory footprint. In order to solve these two issues, I suggest
> to drop the use of the W3C DOM in webdav in favor of something easier and
> more straight forward to use.
> One candidate could be (out of my head and based on my bias towards KXml)
> KDOM. See also http://www.kxml.org.ww
> See also JCR-1261 for more discussions on this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
