Saxon

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).

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.

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.