ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: Performance Comparison
Date Tue, 04 May 2010 09:21:08 GMT
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


Mime
View raw message