Saxon

Thanks for letting us know about it - we'll try and investigate the causes.

First though, to reproduce your measurements we need the missing functions.xsl file.

I actually don't think any of the functions/templates in the functions.xsl are used in the templates, but just in case, here you go.

I think I can explain, without first reproducing it, why the call-template version should use more heap space.

Note that tail-call optimization works differently for templates and for functions. What I am saying here applies to xsl:call-template and not necessarily to tail function calls or to tail calls on xsl:appiy-templates.

There are in effect two stacks around at run-time: the Java (JVM) stack, and the XSLT stack. Tail-call optimization for templates prevents a tail call consuming space on the Java stack, but it does not prevent it consuming space on the XSLT stack (which is held in the Java heap). Since local XSLT variables are held in the XSLT stack, this may consume a significant amount of memory.

It would be interesting to see how an implementation using tail function calls compares (or for that matter, one using fold-left()). Tail call optimization for functions works differently - it compiles the recursive function into a loop. As a result, it only works for self-recursion (which means it is not applicable to the xsl:apply-templates case, though the same technique could be used for a self-recursive named template).

I'm more concerned about the bytecode effects. Running with bytecode enabled should never make performance worse.

I'm not getting very far in determining why the bytecode version is slower (in my case, about 50% slower).

Java CPU tracing shows that in the bytecode case, a very large number of the hits are in generated code. That's a sign that bytecode generation is making a difference, but it can be a difference either way. Unfortunately it's very difficult to determine where in the bytecode the hotspot is; the trace indicates line 197 of the XSLT code, but there's no sign of anything unusual happening there. I've traced the bytecode and it all seems to be running as expected.

I've traced how many MemoClosures get created, which is sometimes an indicator of differences in execution strategy, and it's identical in both cases.

I decided to take a whack at this this morning. I simplified as much as I could (without any regard to keeping the same output), to whittle the script down to the simplest thing that would still show a difference of performance.

I cut down the script significantly, and I was still seeing about a ~40-50% difference in performance, so I tried changing the keys to maps, and that didn't do anything.

Finally, I tried replacing the most internal iterate command with a single line sum( for each .... return...) command. This led to interesting results that I hope are useful.

The two attached scripts give identical output and they both show a performance degradation when byte-code is switched on. However, the "iterate" version shows a much more significant degradation. The difference in run-time on my machine is about 40-45%. The difference in run-time for the non-iterate version is only about 10-15%.

I'm hopeful that these attachments are useful for either of two reasons:

1. They are both much simpler than the original, so analysis of them in their own right might be easier.
2. They show a contrast in performance pointing to a specific line/block of code.