[ http://issues.apache.org/jira/browse/AXIS2-533?page=comments#action_12416357 ]
Dan Diephouse commented on AXIS2-533: ------------------------------------- My comments on Dim's blog posting: What XML driver are you using with the other DOM implementations? Have you tried using woodstox as the driver with all of them? Woodstox is 30+% faster than the standard sax driver, so I don't know that the above is a fair comparison. Also, have you looked at XOM? It is the fastest DOM that I know of. > Axiom is heavy-weight and slow > ------------------------------ > > Key: AXIS2-533 > URL: http://issues.apache.org/jira/browse/AXIS2-533 > Project: Apache Axis 2.0 (Axis2) > Type: Bug > Components: om > Versions: 0.95 > Environment: n/a > Reporter: Dennis Sosnoski > Attachments: ombench.zip, perf.xls, sizes1.ods, sizes1.xls, sizes2.ods, > sizes2.xls, times1.ods, times1.xls, times2.ods, times2.xls, try.sh > > In performance tests comparing Axiom with JDOM, dom4j, and Xerces DOM > document models Axiom was consistently both slower and bulkier than the other > OMs when the tree was expanded. Axiom delivered good performance for the > initial "parse" operation only by virtue of not building the tree. Here are > some time comparison figures for Axiom vs. dom4j on a fairly large SOAP > response (from the MS interop suite): > Running Axiom with 10 passes on file docs/xmlformatter.xml (274920 bytes): > Build mn=563 Build av=5110 Walk mn=33360 Walk av=60885 Build-Walk > mn=33923 > Build-Walk av=65995 Write mn=31774 Write av=52782 Mod mn=5 Mod av=6 > Running dom4j with 10 passes on file docs/xmlformatter.xml (274920 bytes): > Build mn=24816 Build av=28843 Walk mn=2839 Walk av=3055 Build-Walk > mn=27655 > Build-Walk av=31898 Write mn=18866 Write av=19369 Mod mn=5 Mod av=6 > The most interesting figures here are the Build-Walk time (sum of > microseconds for the initial parse operation plus walking the document tree, > which forces Axiom expansion) and the Write time. The average times are > especially bad by comparison with dom4j, which I'd suspect is caused by a lot > of temporary object creation. The write times may be at least partially > caused by the XMLStreamWriter API, since only Axiom uses this approach for > output. Here are memory comparisons: > Running Axiom memory test with 4 passes on file docs/xmlformatter.xml (274920 > bytes): > Init mem=451872 Chg mem=928 First sz=15192 Avg sz=15261 Walked > sz=2071960 > Avg+Walked sz=2087221 > Running dom4j memory test with 4 passes on file docs/xmlformatter.xml (274920 > bytes): > Init mem=829968 Chg mem=3120 First sz=1031760 Avg sz=971976 Walked sz=0 > Avg+Walked sz=971976 > The interesting figures here are the Avg+Walked sz values, which give the > total bytes of memory in use after parsing and walking the document > representation. > Here are the same time and memory test results for a collection of smaller > SOAP documents: > Running Axiom with 10 passes on directory docs/soaps (30 files totaling 19407 > bytes): > Build mn=13610 Build av=16897 Walk mn=2332 Walk av=10523 Build-Walk > mn=15942 > Build-Walk av=27420 Write mn=16079 Write av=22565 Mod mn=9 Mod av=9 > Running dom4j with 10 passes on directory docs/soaps (30 files totaling 19407 > bytes): > Build mn=7507 Build av=12354 Walk mn=121 Walk av=134 Build-Walk > mn=7628 > Build-Walk av=12488 Write mn=4226 Write av=5012 Mod mn=10 Mod av=10 > Running Axiom memory test with 4 passes on directory docs/soaps (30 files > totaling 19407 bytes): > Init mem=456104 Chg mem=1640 First sz=451960 Avg sz=449760 Walked > sz=103520 > Avg+Walked sz=553280 > Running dom4j memory test with 4 passes on directory docs/soaps (30 files > totaling 19407 bytes): > Init mem=836392 Chg mem=7944 First sz=103824 Avg sz=33768 Walked sz=0 > Avg+Walked sz=33768 > Note the huge memory usage in this case. It appears that Axiom has a high > per-document memory overhead, perhaps caused by holding on to the > XMLStreamReader (which suggests the references to the reader should be > cleared as the tree is constructed, so that once the tree is complete the > reader can be garbage collected). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
