axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [Axis2] OM
Date Tue, 02 Nov 2004 09:41:00 GMT
Dennis Sosnoski wrote:

> I spent the weekend catching up with the last couple of months of Axis 
> emails and saw some of the activity around the OM. I have a few 
> thoughts I wanted to offer on this.
> First off, if you really want to keep performance high then I urge you 
> not to build a model. I'd instead suggest something like a parse event 
> store that you can replay on demand using StAX, SAX, or custom APIs. 
> Models are expensive in terms of both time and memory. There's been 
> talk of integrating in XMLBeans, and I know XMLBeans already has some 
> form of backing event store for everything it does. I haven't looked 
> into the performance of XMLBeans, but something like that backing 
> store would probably be a great basis for what you need (and even has 
> XPath and such already implemented on top of it).

XmlBeans uses model too (DOM2 like store). it would be interesting to 
see independent performance results including memory footprint

> I've also implemented a simple parse event store for my XBIS project 
> ( - the parse event store is currently designed 
> around SAX, and can be found in the eventstore package 
> This gave excellent 
> performance (I think replaying the event stream at least 10X parser 
> speed) at a resonable memory cost (about 2X the actual size of the 
> document text for the cases I looked at) without much work on 
> optimization. Working with even an efficient document model is likely 
> going to be both considerably slower and considerably heavier in 
> memory usage.

i think that is what we try to do but optimized for SOAP where SOAP 
headers are kept in memory and accessible in whatever API is 
needed/standard such as DOM, SAAJ, etc. - we have to optimize for this 
common case however SOAP body can be retrieved by app directly as event 
stream if required.

currently thinking is around using SAX, StAX, XPP streams but having 
even more optimized stream should only make things better :)

> The real limitation I saw for a parse event store was just that the 
> parser APIs are inefficient for working with the data - attributes 
> have to be kept as memory-consuming Strings rather than just character 
> ranges, and in the case of SAX have to be organized into structures 
> for reporting; namespaces are passed in the form of URIs and prefixes 
> rather than objects (forcing applications to go through the same work 
> the parser has done to associate the two); etc. 

that is precisely point of having OMNamespace in OM API.

> If you actually designed a parse event stream interface rather than 
> working with either SAX or StAX you could probably push the efficiency 
> even higher (in other words, use the event store as an adapter between 
> the parser and your own internal event stream API).

if you have done all hard work then i see why not try to use it :)

what is the license for your API/source code? can it be included in 
AXIS2 (either in OM core or as optional component)?



The best way to predict the future is to invent it - Alan Kay

View raw message