Hi,
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Mark Vakoc
> > Registered RTFs are then freed on every exit of
> xsltApplyOneTemplate().
> > This means that the lifetime of RTFs is managed by Libxslt
> itself. This
> > might be also the reason why there's no "free" function for
> RTFs yet.
>
> A note about this: the lifetime of created RVTs used to give
> me tremendous resource problems in the past, though
> admittedly probably a rare situation. I had an extension
> function that would return database results as RVTs. The
> fact that they were only freed once leaving a template forced
> me to dramatically suboptimally re-write the XSLT to reduce
> the overhead generated. Where I wanted to do:
>
> <xsl:template match="something">
> <xsl:for-each select="my:sql-many-results-func()/results/row">
> <xsl:for-each select="my:some-other-sql-query('some query
> using the previous row'">
>
> </xsl:template>
>
> Not really the best example, but had a few downsides:
> 1. required template matching to work on RVTs (actually
> RVTs converted to node-sets like exsl:node-set() would do),
> which I think is against any spec but Daniel always made it work
I think the spec just doesn't say anything about this. All the
other XSLT processors I know about (Saxon, MSXML 4.0, MS .NET,
Xalan) work the same way.
> 2. sometimes created some very ugly/verbose stylesheets
> 3. still sometimes tough to reduce the memory overhead for
> large RVTs returned.
>
> I remember trying for a long time to improve the granularity
> such that RVTs created within <xsl:for-each> and other
> instructions , underneath elements within a template, or
> generally anywhere a variable would no longer be in scope
> would be freed when you leave that boundary. I could never
> get it to work properly but I'm sure it's possible.
The scope of variables was handled by calling xsltApplyOneTemplate()
on the variable instruction itself; leaving this function also
meant leaving the scope of the variable. As far as I can see the
lifetime of a variable was handled correctly. The change I
applied here (not committed yet), was eliminating the need to
call xsltApplyOneTemplate(); the mechanism just uses now the
depth in the instruction tree; when leaving the depth of visibility
of a var, the var, together with the associated result tree fragment
is freed (or released into a cache). This means result tree fragments
are now directly bound to the vars; the lifetime of a var is
now the only mechanism, which defines the lifetime of the tree fragment.
I think we could easily change this further to cleanup tree fragments,
which were created in/underneath an instruction, directly after an
instruction exits - if this is what you mean. Taking xsl:for-each
as an example, the tree fragments created underneath were already
freed on the exit of an iteration - the content of xsl:for-each
was processed with xsltApplyOneTemplate(). The only change we need to
apply here, is to free tree fragments when the xsl:for-each instruction
exits; and this could be done centralized at the place where all
instructions are invoked: xsltApplyOneTemplate() (or
xsltApplySequenceConstructor() in the new code).
I'll look into this.
> Alas, it's not a problem for me anymore (I've moved for good
> or bad to the java world for development*), but thought it
> worth mentioning if someone is looking at how the RVTs could work.
Yes! Information like this is highly wellcome.
> * Got to say I miss the speed and nicer API of libxslt over
> pure DOM and java xml standards, I've written wrappers for
> DOM like the libxml2 tree.h APIs to make it more tolerable.
> Will say the that XPATH 2.0 is quite powerful though.
True, I'm also dreaming of a white XPath 2.0 :-)
Thanks & regards,
Kasimier
_______________________________________________
xslt mailing list, project page http://xmlsoft.org/XSLT/
[email protected]
http://mail.gnome.org/mailman/listinfo/xslt
