Performance regression working with XSLT

Dear all,

I am optimizing a workflow for best possible performance. Four approaches were created which convert the following (example) XML

<?xml version="1.0" encoding="UTF-8"?>
  <fragment ID="ANYVALUE">
</fragment>

into ā€¦

<?xml version="1.0" encoding="UTF-8"?>
<Value AttributeID="ID">ANYVALUE</Value>`

The approaches are:

  1. Column List Loop Start > String Manipulation > String to XML
  2. Column List Loop Start > String Replacer > String to XML
  3. Unpivoting > String Replacer > String to XML > Pivot > Column Rename > RowID
  4. Unpivoting > XSLT > Pivot > Column Rename > RowID

I used the Vernalis benchmark nodes and executed each approach 25 times. Each appraoch was executed in sequence after garbage collection ran and the workflow was saved.

Whilst I thought the more simplistic each approach is, less less it has to loop, the better the performance. Though, it seems the most straight forward via XSLT yields the worst performance by a significant margin (left to right resembles first to last approach):

The XSLT I sued is:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output encoding="UTF-8" version="1.0">
</xsl:output>
<xsl:template match="/fragment">
    <xsl:element name="Value">
        <xsl:attribute name="AttributeID">
            <xsl:for-each select="@*">
                <xsl:value-of select="name()">
                </xsl:value-of>
            </xsl:for-each>
        </xsl:attribute>
        <xsl:value-of select="/fragment/@*[1]">
        </xsl:value-of>
        <xsl:apply-templates>
        </xsl:apply-templates>
    </xsl:element>
</xsl:template>
</xsl:stylesheet>

Please note that without the for-each xsl transformation the attribute name would get lost i.e. when using:
<xsl:value-of select="/fragment/@*[1]/name()" />
or
<xsl:value-of select="/fragment/name(@*[1])" />

Is the XSLT node yt not optimized?

Edit: Here is the workflow ā€¦

Thanks in advanced for your feedback
Mike

Iā€™m not sure there is anything to optimize in the XSLT node. We are simply using the standard Java classes for applying XSLT to XML documents. It may be possible to cache the compiled XSLT, though. Maybe that results in some improvements.

2 Likes

I think the regression is simply due to the fact the even this very simple XSLT does a lot of things. Way more than the other approaches. I.e. I do recall that the memory food print was significantly larger when using XSLT. Though, I may recall that incorrectly.

Anyways, thanks for checking.

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.