Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: XSL Improvement

From: steveg@---------.---
To: NULL
Date: 2/1/2005 5:19:00 AM
Mike,

Thanks for the reply.

I've been using the //ClaimInformationLoop in my XSL for a while and
while I know it's not terribly efficient, it's been good enough.  Prior
to adding the use of the preceding-sibling axis I was able to transfor
a 60MB inbound XML document in about 7 minutes which is fast enough
considering I'm making COM calls via VBScript, using
//ClaimInformationLoop, and probably doing dozens of other stupid
things.  Since adding the preceding-sibling to my XSL I haven't had my
XSL complete successfully on a large document.  My box goes to 100% CPU
utilization and sits there for 30+ minutes before I get impatient and
kill the transform.

To answer your question about the document growth I would say that the
majority of the growth is in <Transaction837> nodes.  I'll probably get
a factor of ten increase in the number of <UserHierarchicalLevelLoop>
and <PatientHierarchicalLevelLoop> pairs but I'll see a 100 to 1000
fold increase in the number of <Transaction837P> nodes.

That's actually one of the things that stumps me about this as I don't
understand why the preceding-sibling is so inefficient in my case.
Normally, I won't have more than a dozen or so preceding-sibling
matches which doesn't strike me as a lot to search through and the
efficiency shouldn't be affected by the number of <Transaction837P>
nodes just the number of siblings which stays relatively constant and
relatively small.

Again, thanks for any insight you can offer.

BTW, I'm using v1.1 of the .NET framework to do my transform if that
helps.

Steve

rdcpro wrote:
> This will always slow things down:
>
> <xsl:for-each select="//ClaimInformationLoop">
>
> Use an absolute path, if possible. If not, you can sometimes make big

> improvements by iterating over the nodes in an xsl:key.
>
>
>
> Are these documents very large because there are a lot of
<Transaction837P>
> nodes, or because there are a lot of <UserHierarchicalLevelLoop>  /
> <PatientHierarchicalLevelLoop> pairs in a single <Transaction837P>?
>
>
> Regards,
> Mike Sharp
>
> "steveg@p..." wrote:
>
> > I'm new to XML and XSL so bear with me.  I'm trying to use XSL to
> > transform an inbound XML document into a different XML structure
which
> > can then be consumed by another in-house application.  The
documents
> > can be quite large so performance is important.  I've been
stumbling
> > along and have successfully transformed everything I've come across
but
> > the latest required transform is miserably slow.  I've tracked it
down
> > to the use of the preceding-sibling axis but I'm not savy enough to
> > know how to work around the problem.
> >
> > Any help is appreciated.
> >
> > In my example, I'm processing the ClaimInformationLoop becasue the
vast
> > majority of information I need access to is in this node or its
> > children.  However, some of the information is in the
> > PatientHierarchicalLevelLoop parent node and some in the
> > UserHierarchicalLevelLoop node.
> >
> > Here's a much simplified example XML and XSL which gives the output
I
> > want but is terribly slow on large documents.
> >
> > TIA,
> > Steve
> >
> > <?xml version="1.0"?>
> > <file>
> > <Transaction837P>
> > <SubmitterNameLoop/>
> > <ReceiverNameLoop/>
> > <Billing_Pay_toProviderHierarchicalLevelLoop/>
> > <UserHierarchicalLevelLoop>
> > <UserNameLoop>
> > <UserName LastName="LAST1" FirstName="FIRST1"/>
> > </UserNameLoop>
> > <PayerNameLoop/>
> > </UserHierarchicalLevelLoop>
> > <PatientHierarchicalLevelLoop>
> > <ClaimInformationLoop/>
> > </PatientHierarchicalLevelLoop>
> > <UserHierarchicalLevelLoop>
> > <UserNameLoop>
> > <UserName LastName="LAST2" FirstName="FIRST2"/>
> > </UserNameLoop>
> > <PayerNameLoop/>
> > </UserHierarchicalLevelLoop>
> > <PatientHierarchicalLevelLoop>
> > <ClaimInformationLoop/>
> > </PatientHierarchicalLevelLoop>
> > <UserHierarchicalLevelLoop>
> > <UserNameLoop>
> > <UserName LastName="LAST3" FirstName="FIRST3"/>
> > </UserNameLoop>
> > <PayerNameLoop/>
> > </UserHierarchicalLevelLoop>
> > <PatientHierarchicalLevelLoop>
> > <ClaimInformationLoop/>
> > </PatientHierarchicalLevelLoop>
> > </Transaction837P>
> > </file>
> >
> >
> >
> > <?xml version="1.0"?>
> > <xsl:transform version="1.0"
> > xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> > xmlns:msxsl="urn:schemas-microsoft-com:xslt">
> > <xsl:output method="xml" version="1.0" indent="yes"
> > omit-xml-declaration="yes"/>
> >
> > <xsl:template match="/">
> >
> > <xsl:element name="root">
> >
> > <xsl:for-each select="//ClaimInformationLoop">
> > <xsl:element name="CLAIM">
> > <xsl:attribute name="LAST_NAME"><xsl:value-of
> >
select="../preceding-sibling::UserHierarchicalLevelLoop[1]/UserNameLoop/UserName/@LastName"/></xsl:attribute>
> > <xsl:attribute name="FIRST_NAME"><xsl:value-of
> >
select="../preceding-sibling::UserHierarchicalLevelLoop[1]/UserNameLoop/UserName/@FirstName"/></xsl:attribute>
> >
> > </xsl:element>
> > </xsl:for-each>
> > </xsl:element>
> >     
> > 	</xsl:template>
> > 
> > </xsl:transform>
> > 
> >



transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent