Thanks for the extra info. Yes, I think one can assume that the startup
overhead becomes negligible as the data volume increases: but your
assumption that compilation time should be excluded only for products that
compile to bytecode (or similar) is certainly unwarranted, Saxon does a lot
of work at compile time to reduce run-time costs.
It's interesting that with Saxon, unlike all the other processors, the
throughput is still increasing at the 80Mb point.
It's not immediately clear why the XSLT code should perform better than
XQuery: I suspect that the difference is that the XSLT code is not
constructing a physical result tree, but is rather piping constructed nodes
straight into the serializer. The presence of the function call in the
XQuery code probably prevents this happening: each output element will
probably be constructed first, then copied to its parent element.
It's interesting that -pull gave some benefit - it sometimes does and
sometimes doesn't, and I need to do more work to discover what factors
affect this so that I can automate the decision which mode to run in.
> -----Original Message-----
> From: saxon-help-bounces@...
> [mailto:saxon-help-bounces@...] On Behalf
> Of Alain Frisch
> Sent: 28 June 2006 16:36
> To: saxon-help@...
> Subject: [saxon] XStream
> I'd like to announce a new small language for XML
> transformation, called XStream. Transformations written in
> XStream are compiled into efficient XML stream processors:
> the output is computed and produced while the input is being
> parsed, which makes it possible to run some transformations
> on very big XML documents which could not even fit in memory.
> Though XStream is mostly intended as a back-end for
> higher-level languages, it is also possible to use it
> directly. The language features ML-like pattern matching and
> higher-order functions, but no types.
> Web-site: http://yquem.inria.fr/~frisch/xstream
> The reason I'm posting this announce here is that I did a
> tiny benchmark to compare the performance of a transformation
> written in XStream, and the same transformation written in
> XQuery and XSLT, with several XQuery/XSLT engines. You can
> find the results here:
> As you can see, Saxon/XQuery performs roughly as well as Qizx/open.
> Saxon/XSLT performs better than Xalan C++ and xsltproc
> (Gnome's libxslt), but Xalan's XSLTC is slighlyt better.
> XStream outperforms all these implementations. If someone can
> propose more efficient versions of the XSLT or XQuery
> scripts, or tell me which configuration settings could
> improve Saxon performance, I'd be happy to run the benchmarks again.
> (Note that I'm not claiming any superiority of XStream over
> XQuery or XSLT implementations: the data models and the
> languages are too different.)
> Alain Frisch
> Using Tomcat but need to do more? Need to support web
> services, security?
> Get stuff done quickly with pre-integrated technology to make
> your job easier Download IBM WebSphere Application Server
> v.1.0.1 based on Apache Geronimo
> saxon-help mailing list