Mailing-List: contact java-dev-help@axis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@axis.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4BDFE704.5060107@sosnoski.com>
Date: Tue, 04 May 2010 21:21:08 +1200
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090822)
MIME-Version: 1.0
To: Andreas Veithen <andreas.veithen@gmail.com>
CC: Daniel Kulp <dkulp@apache.org>, wss4j-dev@ws.apache.org,
        java-dev@axis.apache.org, commons-dev@ws.apache.org
Subject: Re: Performance Comparison
References: <y2n1e8c1ed41004281554hd28bda8p70093dc691c1c4e4@mail.gmail.com>
 	<AANLkTiklYf0zyOfAzLYcKxoaSU3EX56LRN58ka90Sqf1@mail.gmail.com>
 	<4BDEAC32.6000307@sosnoski.com> <201005032119.05950.dkulp@apache.org>
 	<4BDF80DC.7020308@sosnoski.com>
 <AANLkTinrCV_1XDTPN1CYA3ioEHTjHCVLT5thtahoqRTM@mail.gmail.com>
In-Reply-To: <AANLkTinrCV_1XDTPN1CYA3ioEHTjHCVLT5thtahoqRTM@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andreas Veithen wrote:
> On Tue, May 4, 2010 at 04:05, Dennis Sosnoski <dms@sosnoski.com> wrote:
>   
>> ...
>>>       
>> The nice thing about using a slightly-hacked and simplified DOM is that
>> everything would be automatic - as it is with Axiom now, but with
>> considerably less memory and processor overhead (because this approach would
>> *only* defer building the DOM representation of the Body content, and would
>> build the entire Body content as a DOM whenever anything within the Body was
>> accessed - a lot of the memory and processor overhead of Axiom relates to
>> the incremental one-element-at-a-time build process). And because it'd still
>> implement the DOM interface (or at least a subset suitable for use by WSS4J)
>> applications using WSS4J could choose to use this or continue to use any
>> other DOM they want.
>>     
>
> Your statement assumes that the memory/processor overhead in Axiom is
> caused by the deferred parsing/building support. I don't think that is
> true. I think the reason is simply the way (the default
> implementations of) Axiom stores the information. For example, storing
> the attributes and namespace declarations of an element in hash maps
> is probably suboptimal. In SOAP messages, the average number of
> attributes (resp. namespace declarations) on elements having at least
> one attribute (resp. namespace declaration) is probably less then 2.
> Therefore the overhead of creating and maintaining a hash map is
> probably not justified by any gain in access performance.
>   

Yes, I can see that it'd be possible to implement a deferred 
parsing/building approach at the element level without much added memory 
or processing overhead, if done correctly. There can really only be one 
parser in use, for instance, so that can be stored at the document 
level, and even the element currently being expanded could be stored at 
that level (rather than using a flag on the element). But is the 
flexibility gain from doing things this way worth the added complexity, 
as opposed to my suggestion of a tweaked DOM with a special kind of 
expandable Element used only for the Body (well, actually two kinds of 
expandable Elements, the second to handle MTOM attachments)? I don't know.

  - Dennis

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@axis.apache.org
For additional commands, e-mail: java-dev-help@axis.apache.org