The converse of what? Speed or memory? Holger's stylesheet creates
variables, but one type of variable (a result tree fragment) is much more
expensive than another type (a string). It seems a similar situation to me
-- creating something is always more expensive than not creating something.
In this case, it's named object instead of the temporary result of an
expression
Certainly using a variable will be a lot slower, since we have to look in
the stack for the variable. Right now, that's an iterative comparison of
variable names in the active stack frame.
Scott did some work in Xalan-J to track variables as offsets, like the code
a compiler would generate. We should do that as well, but there's not a
lot of work being done on the C++ processor right now.
Dave
"Rick Bullotta"
<rick.bullotta@light To: <[EMAIL PROTECTED]>
hammer.com> cc: (bcc: David N
Bertoni/Cambridge/IBM)
Subject: RE: Transforming memory
grows (Xalan-C)
03/27/2002 09:02 AM
Please respond to
xalan-dev
Interesting, the converse seems to be true when using variables.
When processing the same stylesheet using:
<xsl:variable select="xxx"/>
versus
<xsl:variable><xsl:value-of select="xxx"/></xsl:variable>
The latter approach is SIGNIFICANTLY faster.
Any explanation you can think of?
Rick Bullotta
CTO
Lighthammer Software (www.lighthammer.com)
-----Original Message-----
From: David N Bertoni/Cambridge/IBM [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 27, 2002 11:56 AM
To: [EMAIL PROTECTED]
Subject: Re: Transforming memory grows (Xalan-C)
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
