I spent some time today looking at the anomalous results for Q12. I found one inefficiency in the compiled code: it wasn't using lazy evaluation for an expression that had been moved out of a loop, which meant that the expression was sometimes being evaluated even though the loop ended up being executed zero times. But this turned out not to account for much of the disrepancy in the numbers. In fact the discrepancy turns out to be a measurement error: the column of figures for Saxon-SA are in fact Saxon-SA running against a version of the tests modified to use a schema; so the interpreted and compiled code weren't actually executing the same query. Corrected measurements are: Query Saxon-B Saxon-SA compiled q1 6.6 6.8 1.8 q2 6.0 5.9 4.8 q3 22.0 21.6 15.3 q4 21.8 24.6 17.6 q5 6.8 6.5 4.2 q6 4.4 4.1 4.3 q7 32.6 33.7 34.1 q8 12217.7 54.7 22.3 q9 16700.7 66.1 52.7 q10 1735.7 177.0 278.6 q11 12528.0 4140.9 5671.5 q12 3234.7 3141.5 2633.7 q13 3.2 3.2 3.1 q14 152.2 122.3 112.4 q15 4.8 4.6 4.2 q16 8.4 8.4 4.3 q17 11.6 12.2 6.8 q18 11.2 11.9 8.2 q19 65.5 65.7 118.5 q20 34.9 36.4 24.6 This still leaves Q10, Q11, and Q19 needing investigation. Although the aim is to achieve a doubling of performance overall, the first step is to ensure that no query runs slower when compiled than it does under the interpreter