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
