axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davanum Srinivas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AXIS2-533) Axiom is heavy-weight and slow
Date Thu, 15 Jun 2006 16:23:32 GMT
    [ http://issues.apache.org/jira/browse/AXIS2-533?page=comments#action_12416358 ] 

Davanum Srinivas commented on AXIS2-533:
----------------------------------------

And my reply :)

The suite was developed by Dennis, the code is here:
http://svn.apache.org/repos/asf/webservices/axis2/archive/java/scratch/dennis/

Details on the tests are here:
http://issues.apache.org/jira/browse/AXIS2-533

No, i just ran the tests that he provided. He did not have a driver for XOM.


> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message