Project

Profile

Help

xslt/xquery -> java code

Added by Anonymous over 16 years ago

Legacy ID: #4808384 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

Hello Mr. Kay, Have you considered java/c#/? generation from your optimized expression tree? I think whenever one uses typed variables it's possible to generate good java code, especially for singletons. It's understood that such generation can impact on lazy evaluation (e.g. for singletons, to store values of scalar variables), and possibly will demand more from extended elements. As for schema aware generation, it's possible to go as far as to generation of beans corresponding to the schema types/elements, whenever this will lead to optimal code.


Replies (3)

Please register to reply

RE: xslt/xquery -> java code - Added by Anonymous over 16 years ago

Legacy ID: #4808397 Legacy Poster: Michael Kay (mhkay)

Saxon-SA does generate Java code from XQuery, see http://www.saxonica.com/documentation/using-xquery/querycompilation.html for details. It doesn't generally give a vast performance improvement, usually 25% - 50% speed-up. Any feedback will be welcome (there has been remarkably little to date).

RE: xslt/xquery -> java code - Added by Anonymous over 16 years ago

Legacy ID: #4810044 Legacy Poster: Vladimir Nesterovsky (vnesterovsky)

I've tried this feature with "saxon-resources9-0-0-1\samples\query\tour.xq", as it's a good example for a test. At first look I thought there was a wide field for the optimization, however the more I've looked, the more I've recognized the need to do it the way it done. However, I would try to approach singleton variables closer to java types. I've expected to see: // // declare function tour:find-best-move at line 192 // private I fn_find_best_move_4_8( I_opt param0, // $board I_opt param1, // $possible-moves I param2, // $fewest-exits I param3, // $best-so-far for declare function tour:find-best-move ( $board as xs:integer*, $possible-moves as xs:integer*, $fewest-exits as xs:integer, $best-so-far as xs:integer ) as xs:integer { where I is either int, long, Integer, BigInt or somethig like this, and I_opt could be an optional variant of I, or even pair of parameters I, boolean. A following lines: let $trial-move as xs:integer := $possible-moves[1] could be translated more efficiently than: // line 205 final SequenceIterator v22 = Value.asIterator(param1Final); final Item first23 = v22.next(); if (first23 == null) { dynamicError("An empty sequence is not allowed as the value of variable $trial-move", "XPTY0004", context); } // let $trial-move := ... final Item variable4 = first23; I would also try to use java's arithmetic, whenever a promoted type is known at compile time, rather than wrapping it.

RE: xslt/xquery -> java code - Added by Anonymous over 16 years ago

Legacy ID: #4810074 Legacy Poster: Michael Kay (mhkay)

Yes, you are right: direct use of native Java types rather than their Saxon boxed equivalents is the biggest opportunity for improving the speed. It's particularly difficult with integer, because Saxon supports indefinite-length integer arithmetic. There probably needs to be an option when compiling to suppress this feature and limit it to 64-bit. But the other problem is that I think it needs the code generator to work in two passes so that the usage of variables can be analyzed, and that's a major change in the design of the code.

    (1-3/3)

    Please register to reply