[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-dev
Subject:    [jira] Commented: (AXIS2-533) Axiom is heavy-weight and slow
From:       "Dennis Sosnoski (JIRA)" <jira () apache ! org>
Date:       2006-03-31 21:39:56
Message-ID: 1193485563.1143841196964.JavaMail.jira () ajax
[Download RAW message or body]

    [ http://issues.apache.org/jira/browse/AXIS2-533?page=comments#action_12372725 ] 

Dennis Sosnoski commented on AXIS2-533:
---------------------------------------

Absolutely, dims - I checked the box on the form to say I was licensing it for ASF \
use. Let me know if there's anything you'd like to try out - the test code is a \
little convoluted because it's based on a general framework.

> 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


[prev in list] [next in list] [prev in thread] [next in thread]