[EMAIL PROTECTED] wrote:
>
> I've been doing a *lot* of running benchmarks and profiles of Xalan
> [DTM_EXP] the last two weeks. One of the real hotspots that has come up is
> variable and parameter execution. Basically, our current mechanism sucks
> right now, and has got to go.
> ...
> Does this sound reasonable? Can I do it without screwing things up? This
> should improve performance a fair amount for certain classes of
> stylesheets, and actually improve performance a little bit for all
> stylesheets, even if they don't use variables (because we won't have to be
> doing push/popContextMarker for every element). The variable mechanism
> tends to be very delicate, but I think this should be pretty robust out of
> the box, and shouldn't effect the actual variable evaluation (i.e. lazy
> evaluation and stuff like that). Or am I deluding myself?
>
> -scott
Scott --
I think that resolving the VarStack location of variables and parameters
faster is a great idea. I'm sure the details may get a little
complicated as you proceed with the actual implementation, but you get a
+1 from me on the idea.
I'm fairly certain, as you state, that xsl:call-template will need to be
resolved at compose() time since you don't know what template you'll
actually be calling until then. I don't think this is resolved at
compose time now (though I may be wrong) so you'll need to figure that
out at compose time and perhaps that information, also, could be saved
so that locating the target template at runtime can avoid a runtime hash
lookup, which is, I think, the way it works now. This would be an added
bonus. If that turns out to be too much work for this go around, I
suppose you could fall back to xsl:apply-templates like processing for
xsl:call-template.
As far as the xsl:with-param stuff (for both xsl:call-template and
xsl:apply-templates), I guess you'll have to copy the value of the
parameter in the calling template slot into the called template slot.
Is that right? I say that because when a Variable occurs, it has a
choice of only the current template stack frame or the global stack
frame, as I understand your design (10b). However, when you copy it,
you'll have to remember from whence it came because the evaluation needs
to be done in the context of where the xsl:with-param occurred, not the
context of the xsl:parameter. I'm not sure where this is remembered now
since I haven't looked at it in a while. Also, does it then get copied
back to the invoking slot? If not, it will have to be reevaluated the
next time it's passed which is not a good thing. If the expression in
the xsl:with-param, in turn, references other parameters that get
passed, this will have to be represented/remembered somehow.
If I understand your design correctly (which is not likely :)), I think
you may run into problems with a situation like this:
<xsl:template match="a">
<xsl:apply-templates select="b">
<xsl:with-param name="a" select="b/c/d"/>
</xsl:apply-templates>
</xsl:template>
<xsl:template match="b">
<xsl:param name="a"/>
<xsl:apply-templates select="c">
<xsl:with-param name="b" select="$a/foo | bar"/>
</xsl:apply-templates>
<xsl:template>
<xsl:template match="c">
<xsl:param name="b"/>
<xsl:copy-of select="$b"/>
</xsl:template>
When the xsl:copy-of gets executed, where is the slot that the
expression and result go in? In b or c? As we evaluate b in the
context of template b, we need to switch to context a to evaluate
variable a. Then, does the evaluated value of variable a remain in the
slot in a?
Anyway, I haven't really thought this through but you get the idea.
If you feel that your design resolves these issues, there is no need to
take the time to correct my understanding of it. Just do it and we'll
all be able to have a look. I only point these issues out to make sure
that you've thought of them, since you did ask.
Gary
