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

Reply via email to