Saxon

The byte code generation feature is where we selectively generate byte code representing sub-expressions in the AST of the compiled stylesheet. Please take a look at the documentation on the byte code generation feature:

http://www.saxonica.com/documentation/index.html#!changes/optimization/9.3-9.4

I would like to investigate further what is causing the slowdown when byte code generation is on. It is possible that some path has not generated the byte code efficiently. There is also a possibility that this may be a known bug which has been fixed since 9.4.0.6.

Please may you send us a repro that we can reproduce the performance difference. You can either attach it to the bug issue or send it privately via email if confidential.

Thanks,

O'Neil

Here is a simplified test harness that just runs the compile. It takes

three command line arguments as shown in the examples below.

The first argument is the number of iterations to run.

The second is a Boolean to indicate whether the processor should run in

licensed mode or not. True = licensed mode.

The third is a Boolean to disable the GenerateByteCode option. True =

disabled.

The first example runs in licensed mode with byte code generated NOT

disabled. As you can see, it takes progressively longer to compile the

same XSLT on each iteration.

[image: Inline image 1]

The second example runs in licensed mode with byte code generation

disabled. Compile performance is much more consistent.

[image: Inline image 2]

The third example runs in non-licensed mode with byte code enabled.

Compile performance is similar to example #2.

[image: Inline image 3]

On Mon, Jun 16, 2014 at 11:52 AM, Saxonica Developer Community <

dropbox+saxonica+f38e@plan.io> wrote:

I reviewed this with O'Neil yesterday; we came to the conclusion that the problem is similar to that described in https://saxonica.plan.io/issues/1833 for the Java case. I know we've investigated something similar recently but I can't find a tracker entry for it. Essentially, on older versions of .NET, when classes/types are dynamically loaded, they remain locked in memory and are never garbage collected. So if you compile a stylesheet with bytecode generation enabled, the memory this uses is never freed until the .NET instance shuts down. This explains the gradual increase in memory usage as you compile more stylesheets, and I think it also explains the performance degradation.

Our plan is to solve this in Saxon 9.6 by taking advantage of the fact that in .NET 4.0 and later, dynamically loaded types can be garbage collected; to make this work we have to build Saxon using a newer version of IKVMC, which also has the effect that Saxon stops working with older versions of .NET. For this reason, we don't think it's appropriate to do this in a maintenance release. As a workaround with Saxon 9.5, we advise disabling bytecode generation at the Processor level for workloads where this problem arises. As mentioned under #1833, we have introduced a more fine-grained switch controlling bytecode generation at the individual stylesheet/query level for 9.6, but in 9.5 it can only be done globally.