[ http://issues.apache.org/jira/browse/AXIS2-533?page=all ]
Dennis Sosnoski updated AXIS2-533:
----------------------------------
Attachment: ombench.zip
Benchmark source code and libraries, with Eclipse project files and try.sh to
run tests. JDOM v1.0, dom4j v1.6.1, Axiom as of yesterday, Xerces 2.7.0
> 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
>
> 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
