Dennis Sosnoski wrote:
Hi Jules,
The problem on the input side is that push-to-pull conversion requires either some combination of storing events (so the push events are stored, then later accessed by pull) and thread switching. Thread switching tends to be expensive - I haven't checked lately, but as of a few years ago it was about the same amount of overhead as parsing a document in the 20K size range - so it's best to minimize this or even eliminate it completely (by first parsing the entire input to the store, then switching to the pull processing).
To handle the storing of events there's code in my XBIS project (http://www.xbis.org) that could be used. This implements a processor- and memory- efficient event store with SAX input and output. Adding an XMLPull adapter should be pretty easy. This is designed for storing an entire document at a time, but could probably also be modified for use as a variable sized queue.
But if your data is in the form of a DOM you should be able to just access it directly with a pull parser interface. I don't know if XMLPull includes code for this purpose, but it would be easy to write it if it's not already around somewhere.
On the output side, it should be easy to write an org.jibx.runtime.IXMLWriter implementation that outputs SAX events. That's all this would take - just code the writer and set it on the MarshallingContext. It might be nice to make this pluggable without the user code needing to set it "manually", but that's just a detail.
thanks, Denis,
now I have a pretty good idea about how we might optimise our system if it proves too slow....
Jules
- Dennis
Jules Gosnell wrote:
Dennis,
I was hoping that I would be able to use JiBX efficiently in e.g. DOM/SAX pipelines - having to drop back into stream format on either side of the JiBX section will add a lot of cycles. It looks like this constraint is imposed by the current XmlPull parser - however the XmlPull FAQ mentions push(SAX)/pull adaptors etc in CVS...
Have you any plans to integrate something like this, to plug pipeline output straight into JiBX ?
I have not investigated the reverse root JiBX->SAX/DOM - is this something that would involve substantial changes to JiBX to do without a temporary streambound phase ?
This is not a showstopper, we just have to throw more cpu at the problem, but, for the longterm, I am interested in your position..
Thanks for your time,
Jules
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ jibx-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-users
------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 _______________________________________________ jibx-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jibx-users
