Saxon

Legacy ID: #3966620 Legacy Poster: Michael Kay (mhkay)

Because the TraceListener interface in Saxon was designed primarily for stylesheet debugging rather than performance monitoring, it disables certain rewrite optimizations that make the flow-of-execution difficult to follow. One of these is tail-call optimization, and it's almost certainly this that is hitting you. Tail-call optimization turns a recursive call into a loop to conserve stack space, and without it you run out of stack after about 500 to 1000 recursive calls. You can sometimes solve this problem by running with a smaller source document. If that doesn't work in your case, I'm afraid I don't have any other good ideas.

Legacy ID: #3966642 Legacy Poster: David Pirkle (dpirkle)

Thanks, I suspected as much. I'll use a smaller source document. One more question: if the tail-call optimization is disabled, does that significantly slow down recursive code? I'm wondering how much I can trust the profile of recursive templates and functions if the profiling is disabling an optimization that is normally enabled.

Legacy ID: #3967013 Legacy Poster: Michael Kay (mhkay)

Tail-call optimization is done essentially to conserve stack space, not to speed up execution, so I don't think this should make your profiling unreliable. There are a few other things done differently when tracing is enabled, for example global variables are evaluated eagerly at the start of the run. Generally this should make the profile data easier to understand, because the effect of many optimizations is to move costs from the place where the code is written to somewhere else. But you're right that it's not an exact science.