suggestion on use of xalan:evaluate() in xsltc

[Reddy Anapalli Amarendra-E65017C <E6...@motorola.com>]

Hi,
 
First of all I am excited by the Great work done at xalan -j .
 
We have a product which is built on servlet , xsl and legacy back -end
technologies to produce web pages. It produced very bad performance
overall though it works fine in all respects. Later detailed analysis
was done to understand the root cause for the performance bottle neck.
 
It is found that in the end-end request flow 65% of the time is consumed
by XSLT interpretive processor keeping the fact that xsl files are
having huge processing instructions.
 
At this stage I have read about complied xslt processor ( XSLTC) and
would like to prototype some of the xsl files taking too much of time to
transform it to html.
 
Basic problem I have is that xalan:evaluate function is used many times
in xsl files to evaluate dynamic stuff.
 
xmlns:xalan=http://xml.apache.org/xalan
<blocked::BLOCKED::http://xml.apache.org/xalan>  
exclude-result-prefixes="xalan"
<!-- usage pattern 1 -->
<xsl:if test="not($SelectedValuePath=$default)">
<xsl:value-of select="xalan:evaluate($SelectedValuePath)"/>
</xsl:if>
<!-- usage pattern 2 -->
<xsl:for-each select="xalan:evaluate($OptionPath)">
<!-- usage pattern 3 -->
<xsl:for-each select="xalan:nodeset($OptionValuePairs)/options//*">
 
I have looked at xsltc documentation, it is clearly mentioned that
EXSLT dynamic extensions like evaluate are not supported because of
design limitations. I am under impression that "nodeset" extension is
compatible.
 
Please suggest me if there is a work around to achieve xalan:evaluate
gets thru in xsltc. How to transform these xsl files to translet using
xsltc.
 
without your help , I am sure my work will be stopped completely. I have
gathered all data about xsltc and encourages our team to take up
this work. If this problem can't be solved then all my efforts will go
in vein.
 
Please suggest.
 
Thanks & Regards,
Amar

Re: suggestion on use of xalan:evaluate() in xsltc

[da...@us.ibm.com]

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