[
http://issues.apache.org/jira/browse/AXIS2-533?page=comments#action_12373428 ]
Dennis Sosnoski commented on AXIS2-533:
---------------------------------------
The performance gains in the latest version look very good, but these are still
using the JRocket JVM. I suggest dropping the memory size to something like 16M
when using JRocket - I haven't tried it, but suspect that'll give a more
realistic test. I'll try updating my Axiom installation and see how it does
with Sun's 1.5 JVM later today.
It's probably best to just drop the init.xml document from the spreadsheet and
charts, by the way, since the point of that one is only to "warm up" the JVM
with the framework code. Also, I didn't implement the modify ("mod mn" and "mod
av") test for Axiom (hence the great time on these!), since I was mainly
interested in the basic construction and serialization time. If anybody wants
to implement these the code for the other frameworks can be used as examples.
> 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
>
> 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
