This is definitely due to the creation of result tree fragments. Right
now, we use one document as a factory for result tree fragments. That's
usually not a problem, but when you create lots of result tree fragments
and they have lots of text, that can cause data to grow uncontrollably.
At any rate, it's _always_ more efficient to avoid the creation of result
tree fragments, so you should always use this:
<xsl:with-param name="arg1" select="substring(.,2)"/>
instead of this:
<xsl:with-param name="arg1">
<xsl:value-of select="substring(.,2)"/>
</xsl:with-param>
whenever you can. This is not a "special" use of xsl:with-param. The
second version always creates a result tree fragment, while the first does
not. The only way we could optimize out a result tree fragment is if we
can determine that you never attempt to use it as a node-set, which is
something we do not do.
One thing I want to experiment with is using a document as the factory for
each result tree fragment, but that has some disadvantages as well.
By the way, don't underestimate the difficulty of tracking variables in a
complex language like XSLT -- it's not as easy as it might seem.
If you can post your document and stylesheet attached to a Bugzilla report,
I will use it when I start the RTF optimization work.
Dave
Holger Floerke
<floerke@doctron To: [EMAIL PROTECTED]
ic.de> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: Re: Transforming memory grows
(Xalan-C)
03/27/2002 07:36
AM
Please respond
to xalan-dev
>In this case you have requested whitespace (line breaks and indentation)
>around the value-of's result. This means XSLT has to create the
>concatenated data. I'm not sure how Xalan-C s handling that, but in
Xalan-J
>you might also be creating a Result Tree Fragment to contain the result of
>that computation (if so, that's an opportunity for optimization). Either
>way, there is going to be some additional heap churn.
>
>As an experiment, you might want to try eliminating the whitespace:
>
> <xsl:with-param name="arg1"><xsl:value-of select="substring
>(.,2)"/></xsl:with-param>
>
>and see whether Xalan-C is clever enough to recognize this as equivalent
to
>the first version.
Nope. The memory stay growing. I'm a little bit confused about the memory
growing all the time during the transformation. If I use "<xsl:value-of..."
and this is a Result Tree Fragment, Xalan-C should free the Fragment as the
"<xsl:call-template" returns, because no one can access the Fragment.
HolgeR
--
holger floerke d o c t r o n i c
email [EMAIL PROTECTED] information publishing + retrieval
phone +49 2222 9292 90 http://www.doctronic.de