Timing Profile

iceandrews · June 3rd, 2015, 04:37 PM

We're running a command line Timing Profile on a certain XSLT that's running on the Saxon 8.9 processor (-TP). It's a very large input message and we have a template that's recursive in nature so it's running over and over and we expect it to occur around 1400 times in this message.

The message processes successfully when TP is turned OFF, but when we try and profile it the profiler stops and spits out this message after about ~1200 calls.

Code:

<template name="Relate" file="*DataAccess.xsl" line="1200" time="1433361673092">
<template name="Relate" file="*DataAccess.xsl" line="1200" time="1433361673092">
<template name="Relate" file="*DataAccess.xsl" line="1200" time="1433361673092">
Error at xsl:call-template on line 1205 of file:/C:/Users/BLERG/Desktop/Enterprise%20Constraints%20Profile/InTrans_DataAccess.xsl:
  Too many nested template or function calls. The stylesheet may be looping.
Transformation failed: Run-time errors were reported

Is there any way to tweak the depth of recursion on the Timing Profiler? We know it's not infinite and would like to complete profile.

Thanks

mhkay · June 3rd, 2015, 04:43 PM

When tracing is switched on (as it is when you use -TP), Saxon disables tail call optimization, which means that recursive templates can blow the stack. The reason is that tail call optimization makes it very difficult to analyze what's going on. If the recursive depth is related to input data size, I suggest you try to do the performance profiling on a smaller document and extrapolate the results.

iceandrews · June 3rd, 2015, 04:53 PM

Excellent response and kind of what I figured. Is there a hard limit to the Timing Profiler tail call detection (like a specific number of loops/memory usage) before it bails out?

While the performance in this case certainly is impacted input message size, it's not a linear performance degradation. So if we reduce the message size, we don't as accurate of performance information on the high end.

mhkay · June 3rd, 2015, 05:21 PM

Saxon is simply detecting a Java StackOverflow and trying to explain it in XSLT terms. If you can find a way to increase the Java stack size then that should help.