RE: [xsl] String conversion problem when string is large

Subject: RE: [xsl] String conversion problem when string is large
From: "Bulgrien, Kevin" <Kevin.Bulgrien@xxxxxxxxxxxx>
Date: Tue, 20 Mar 2012 16:13:00 -0500
-----Original Message-----
From: Jeff Greif [mailto:jeff.greif@xxxxxxxxx]
Sent: Tuesday, March 20, 2012 4:03 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Cc: Bulgrien, Kevin
Subject: Re: [xsl] String conversion problem when string is large

If substring-after() copies bytes, then the recursion is quadratically copying
the initial string.  Passing an offset instead will likely eliminate the
out-of-memory error.

You'd have to be careful not to quadratically build the result string also.

Jeff
-----

Sorry, I don't quite know what is meant by passing the original string with an
offset.

I do know in concept, but I do not know how to express it in code.  I searched
along the lines of pass-by-reference, though have not (yet) turned up any
information that helped me write the code that way.

---

Kevin Bulgrien

On 3/20/2012 12:58 PM, Bulgrien, Kevin wrote:
> -----Original Message-----
> From: Bulgrien, Kevin [mailto:Kevin.Bulgrien@xxxxxxxxxxxx]
> Sent: Tuesday, March 20, 2012 2:06 PM
> To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx'
> Subject: RE: [xsl] String conversion problem when string is large
>
> -----Original Message-----
> From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
> Sent: Tuesday, March 20, 2012 1:39 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] String conversion problem when string is large
>
> The simplest solution is to just find a different XSLT processor, one that
implements tail recursion optimization. Saxon, for example.
>
> You could rewrite the code either to use XSLT 2.0 string handling or to use
divide-and-conquer recursion, but unless there is something that ties you to
your current XSLT processor there is no need to change the code.
>
> Michael Kay
> Saxonica
> -----
>
> I didn't expect that answer... I guess that's encouraging.
>
> I have tried the Java version of SaxonB 9-1-0-8j, but some links appeared to
be broken (or else something on my company proxy choked) on the SourceForge
relative to the most recent .zip of SaxonHE9-4 so I didn't try it before
today.  Since your reply, I tried some creative Googling and turned up a
download link that works.  I'll give try SaxonHE9-4-0-3J.zip a try.
>
> -----
>
> Well, I tried SaxonHE9-4 and got:
>
> $ java -Xms1g -Xmx2g -jar ~/bin/saxon9he.jar -t
> -s:develop/idiffout.xml -xsl:idiffout.xsl -o:idiffout.csv Saxon-HE
> 9.4.0.3J from Saxonica Java version 1.6.0_22
> Warning: at xsl:stylesheet on line 2 column 80 of idiffout.xsl:
>   Running an XSLT 1 stylesheet with an XSLT 2 processor Stylesheet
> compilation time: 437 milliseconds Processing
> file:/home/kbulgrien/cvs/r8000/update/IDiff2DUA/develop/idiffout.xml
> Using parser
> com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser
> Building tree for
> file:/home/kbulgrien/cvs/r8000/update/IDiff2DUA/develop/idiffout.xml
> using class net.sf.saxon.tree.tiny.TinyBuilder
> Tree built in 162 milliseconds
> Tree size: 6616 nodes, 570130 characters, 10303 attributes Exception
> in thread "main" java.lang.OutOfMemoryError: Java heap space
>         at
net.sf.saxon.tree.util.FastStringBuffer.condense(FastStringBuffer.java:485)
>         at
net.sf.saxon.expr.instruct.DocumentInstr.evaluateItem(DocumentInstr.java:308)
>         at
net.sf.saxon.expr.parser.ExpressionTool.evaluate(ExpressionTool.java:320)
>         at
net.sf.saxon.expr.instruct.GeneralVariable.getSelectValue(GeneralVariable.jav
a:529)
>         at
net.sf.saxon.expr.instruct.Instruction.assembleParams(Instruction.java:187)
>         at
net.sf.saxon.expr.instruct.CallTemplate.processLeavingTail(CallTemplate.java:
369)
>         at
net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:615)
>         at
net.sf.saxon.expr.instruct.Choose.processLeavingTail(Choose.java:794)
>         at
net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:615)
>         at net.sf.saxon.expr.instruct.Template.expand(Template.java:231)
>         at
net.sf.saxon.expr.instruct.CallTemplate$CallTemplatePackage.processLeavingTai
l(CallTemplate.java:526)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:239)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.j
ava:199)
>         at
net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:615)
>         at
net.sf.saxon.expr.instruct.Choose.processLeavingTail(Choose.java:794)
>         at
net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:615)
>         at
net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:212)
>         at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1034)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates$ApplyTemplatesPackage.processLeavin
gTail(ApplyTemplates.java:476)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:239)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.j
ava:199)
>         at
net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:615)
>         at
net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:212)
>         at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1034)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:237)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.processLeavingTail(ApplyTemplates.j
ava:199)
>         at
net.sf.saxon.expr.instruct.Choose.processLeavingTail(Choose.java:794)
>         at
net.sf.saxon.expr.instruct.Block.processLeavingTail(Block.java:615)
>         at
net.sf.saxon.expr.instruct.Template.applyLeavingTail(Template.java:212)
>         at net.sf.saxon.trans.Mode.applyTemplates(Mode.java:1034)
>         at
net.sf.saxon.expr.instruct.ApplyTemplates.apply(ApplyTemplates.java:237)
>         at
> net.sf.saxon.expr.instruct.ApplyTemplates.processLeavingTail(ApplyTemp
> lates.java:199)
>
> $ tail -1 idiffout.csv | awk 'BEGIN { FS=","; } { print NF " vs " $9 "
> }' -
> 3954 vs 53392
>
> I don't know if there is a better way to invoke the processor or not, nor if
I should try the .NET version instead.
> I suppose it is possible that something else in the overall transform is to
blame, but the transform exploded in the same spot.
>
> Kevin Bulgrien



This message and/or attachments may include information subject to GD
Corporate Policy 07-105 and is intended to be accessed only by authorized
personnel of General Dynamics and approved service providers.  Use, storage
and transmission are governed by General Dynamics and its policies.
Contractual restrictions apply to third parties.  Recipients should refer to
the policies or contract to determine proper handling.  Unauthorized review,
use, disclosure or distribution is prohibited.  If you are not an intended
recipient, please contact the sender and destroy all copies of the original
message.

Current Thread