axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Sosnoski <...@sosnoski.com>
Subject Re: [Axis2] OM
Date Tue, 02 Nov 2004 17:42:52 GMT
BTW, the XBIS code also contains timing test implementations so you can 
see how long it takes to parse a document directly, to parse to the XBIS 
event store, and to replay the parse from the event store (as well as 
the document format tests that are the main focus of XBIS). It only 
supports SAX parser comparisons at present (and SAX parse event stream 
replay) because that was what I wanted to test against (most widely 
used, and also the only form supported by the JAXP transform for 
generating output document text).

  - Dennis

Dennis Sosnoski wrote:

> Aleksander Slominski wrote:
>
>> Dennis Sosnoski wrote:
>>
>>> 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. ...
>>
>>
>>
>> XmlBeans uses model too (DOM2 like store). it would be interesting to 
>> see independent performance results including memory footprint
>
>
> I've been meaning to run a test (and include .NET's data binding in 
> hopes of getting permission to show the results - I think there's been 
> some legal changes that mean they'll be removing their restrictions in 
> the future). Hopefully I'll get this done in the next couple of weeks.
>
>>
>>>
>>> I've also implemented a simple parse event store for my XBIS project 
>>> (http://www.xbis.org - the parse event store is currently designed 
>>> around SAX, and can be found in the eventstore package 
>>> http://xbis.sourceforge.net/api/index.html). 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 :)
>
>
> Both Srinath's reply and this one clarified this for me. I guess I'd 
> taken the discussion of a "model" too literally and not looked into 
> the details of the implementation. Sounds like you're heading in a 
> good direction (including with the OMNamespace)!
>
>>
>>> 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)?
>>
> My code's BSD in any case, but I'd gladly donate it to the project if 
> you think it's useful. The code's in the download and also in 
> SourceForge CVS from the project site (http://www.xbis.org). I wasn't 
> referring to my code in particular as the event store, though.
>
> Except for the namespace issue I think the XMLPull API is great for 
> working with this type of store. If you'd extend the XMLPull API to 
> use namespace objects (which I'd love to see) you could use that 
> directly. I don't know about StAX - certainly the object API version 
> is going to add a lot of  overhead, and I don't know the details of 
> how the StAX low-level API differs from XMLPull.
>
>  - Dennis


Mime
View raw message