Reddy Anapalli Amarendra writes: >... >It is found that in the end-end request flow 65% of the time is consumed >by XSLT interpretive processor... >Basic problem I have is that xalan:evaluate function is used many times >in xsl files to evaluate dynamic stuff.... [Example:] > <xsl:for-each select="xalan:evaluate($OptionPath)">
The essence of your problem is that you are saying your data varies in structure, and the description of the variances is embedded in each instance of the data. This is a recipe for slow processing! So you should do what you can to minimize the problem. A. Can you have the data served up to you in a consistent structure? (That is, every instance conforms to the same schema?) B. If not (A), is the number of different schemas actually small, and is there an easy way to distinguish them? (In the example above, how many different values of $OptionPath would there be? Or if that variable is derived from some other property of the input data, how many values does that property take on?) C. If part of $OptionPath and similar variables is dependent on interactive user input, can you present the user with a limited range of choices, and put branches in the stylesheet for each choice? D. If not (C), can you focus the user input into a predicate, so that the open-ended evaluate() is replaced by something like <xsl:for-each select="term[name()=$OptName]"> ? E. If all else fails, would it help to use a multi-stage process where you construct a stylesheet (using XSLT with namespace-alias) where $OptionPath becomes the actual expression, then that resulting stylesheet gets compiled? This would be a form of "stored query" for repeated execution. Summary: if you are building paths on-the-fly, you are setting up an interpretive process. If that's too slow, you need to take a deep look at the whole process to make it less arbitrary. .................David Marston