[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Does <xsl:copy> use a lot of memory? Is there an

Subject: RE: Does <xsl:copy> use a lot of memory? Is there an alternative that is more efficient?
From: "Costello, Roger L." <costello@xxxxxxxxx>
Date: Mon, 3 Sep 2012 15:12:40 +0000
RE:  Does <xsl:copy> use a lot of memory?  Is there an
>> In other words, if I don't immediately output the results of
>> xsl:copy, then memory consumption grows and grows. Yes?
>
>Potentially yes.

Okay, then I am in a pickle and I see no way out.

Recall the problem that I am tackling: I have an element with an idref
attribute. I want to fetch the referenced element and inline it. Here's the
template to do that:

    <xsl:key name="ids" match="*[@id]" use="@id"/>

    <xsl:template match="*[@idref]">

        <xsl:variable name="refed-element" select="key('ids', @idref)"/>

        <xsl:copy>
            <xsl:copy-of select="@* except @idref" />
            <xsl:sequence select="$refed-element" />
        </xsl:copy>

    </xsl:template>

However, the element that I just inlined may have a reference. So I store the
results into a variable and then repeat the process on the content of the
variable. But that may also result in inlining an element with a reference, so
I store the results into another variable and process it. I keep repeating
this process until there are no more references. (The references may be
recursive so it is a bit more involved than this, but you get the idea.)

I am processing a 370 MB XML document. The Java version of Saxon gives an "out
of memory" error. I increased the memory size to the maximum that my machine
would allow, 4 GB and I still get the "out of memory" error.

In the process I described above, I am creating a bunch of variables. But with
each new variable that I create, the previous variables are no longer used. It
seems like the previous variables should be garbage collected. Is there a way
to signal to an XSLT processor, "Hey, I am done with this variable, please
garbage collect it"?

/Roger



-----Original Message-----
From: David Carlisle [mailto:davidc@xxxxxxxxx]
Sent: Monday, September 03, 2012 10:06 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Cc: Costello, Roger L.
Subject: Re:  Does <xsl:copy> use a lot of memory? Is there an
alternative that is more efficient?

On 03/09/2012 15:57, Costello, Roger L. wrote:
> In other words, if I don't immediately output the results of
> xsl:copy, then memory consumption grows and grows. Yes?

Potentially yes. But not really because of the xsl:copy, if you changed
it to xsl:sequence you'd probably get the same behaviour. If you are
using lots of variables and don't want them to take up space, you need
to have a very good idea how your xslt processor's optimiser works and
constrain your usage to uses which the optimiser can optimise away....

David


--
google plus: https:/profiles.google.com/d.p.carlisle

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.