classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
Report Content as Inappropriate


Michael Kay
I'm thinking of dropping Saxon's LAZY_CONSTRUCTION_MODE option, but before I do so, I want to know if anyone is likely to scream.

If you don't know what the feature is, then you probably won't miss it, but read on if you are curious. It can be switched on from the XQuery command line using the option -pipe:pull. It allows an expression to evaluate its operands not just as an iterator over a sequence of items, but as an iterator over a sequence of pull-parser-like events. Oddly, though, it has never been integrated with pull parsing.

The main internal impact of the switch is that "temporary trees" (variables containing constructed nodes) are built lazily, that is, the the tree construction is done in parallel with the reading of the tree. But this isn't especially useful, because when a variable contains a tree that will only be read once, the variable is usually inlined at compile time anyway. The default "push" mode of operation generally works better when the final result is serialized, because the final result tree is then never built in memory, but is piped directly into the serializer. The only real benefit is when the receiving application is able to read the result tree one event at a time, as if reading it from a pull parser.

This doesn't affect pipelined processing of sequences. Sequences of items are processed lazily wherever possible, which means that items are only computed as they are needed. But the LAZY_CONSTRUCTION feature extends this so individual items - specifically element and document nodes - can be materialized one event at a time.

All the streaming code in Saxon is based on a push model, so this isn't affected.

The feature was originally added for a company that was doing deep integration of Saxon into a data access framework, where it made sense because of the architecture of their application. But that application is no longer actively marketed and is unlikely ever to be upgraded to a new Saxon release. We haven't really touched the code for years, there aren't many tests, and although the tests pass, we have no idea what would happen if we tried to make it work in combination with the many other things that have been added to the product over the years. I don't like leaving things like that around "just in case", so I'd prefer to kill it.

Shout now, or forever hold your peace.

Michael Kay
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]