ws-sandesha-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Veithen <andreas.veit...@gmail.com>
Subject Re: Performance Comparison
Date Tue, 04 May 2010 11:13:53 GMT
On Tue, May 4, 2010 at 11:21, Dennis Sosnoski <dms@sosnoski.com> wrote:
> 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.

I think it's worth it, because it solves the problem in a completely
generic way (i.e. without making assumptions about the structure of
the document). Also, Axiom 1.x has successfully proven that it is
perfectly possible to support deferred parsing/building on a
node-per-node basis. Of course there are some pieces in Axiom that are
very complex (see e.g. OMStAXWrapper/SwitchingWrapper class), but I
think that is more related to design questions than to the intrinsic
complexity of the approach used by Axiom. Simply this code has grown
over time and nobody took the time to break it down into more
manageable pieces.

I think that dropping deferred parsing/building on a node-per-node
basis would be a regression. In addition, this may have consequences
for Axis2 and may require changes. I think that instead of rewriting
parts of Axis2 to support a new (and less generic) model it is better
to invest that time into something that preserves the model (but that
may be a bit more complex).

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

---------------------------------------------------------------------
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