Does 'match' cost performance?

[Duane Morin]

I've inherited an XSL transform that I need to squeeze every last millisecond out of (since it's running several hundred thousand times). I've noticed that there are 26 match clauses in the file. They are 13 pairs that each check the same condition, like this:

<xsl:template match="A/foo">
....
<xsl:template match="B/foo">
....
<xsl:template match="A/bar">
....
<xsl:template match="B/bar">
....

Get the idea? (The XSL is generated automatically.) So what I'm wondering is, if I restructure the whole thing so that the A/B conditional is checked once, outside the XSL, and thus I get rid of half my match clauses, will I gain any noticeable performance?

Duane

 

[Dimitre Novatchev]

I've inherited an XSL transform that I need to squeeze every last millisecond out of (since it's running several hundred thousand times). I've noticed that there are 26 match clauses in the file. They are 13 pairs that each check the same condition, like this:

<xsl:template match="A/foo">
...
<xsl:template match="B/foo">
...
<xsl:template match="A/bar">
...
<xsl:template match="B/bar">
...

Get the idea? (The XSL is generated automatically.)

One could refactor these as:

*[self::B or self::B]/foo

and

*[self::B or self::B]/bar

So what I'm
wondering is, if I restructure the whole thing so that the A/B conditional is checked once, outside the XSL, and thus I get rid of half my match clauses, will I gain any noticeable performance?

The best way to know is to try.

This will probably not result in any noticeable difference for small transformations, but in your case there might be difference (do not expect anything huge, though).

On the other side, it shouldn't be very difficult in the general case to improve code, which is generated automatically. However, this might involve more complex re-writing and even choosing a better algorithm.

=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Duane Morin]

Let me rephrase my question. I assume that matches are not like if's in the sense that they are all tested and thus the ones that fail are costing you extra processing time. I'll assume that only the proper matches are being executed, so that if my XML has A/foo and A/bar but not B/foo, match="A/foo" and match="A/bar" will succeed.

So, different question -- does the length of the path matter? What if
I did this:

<xsl:template match="A">
....
<xsl:template match="foo">
...
</xsl:template>
<xsl:template match="bar">
...

Is that going to gain me anything? will match="foo" execute faster than match="A/foo" if I know that I'm inside A?

Duane

 

[Dimitre Novatchev]

Let me rephrase my question. I assume that matches are not like if's in the sense that they are all tested and thus the ones that fail are costing you extra processing time. I'll assume that only the proper matches are being executed, so that if my XML has A/foo and A/bar but not B/foo, match="A/foo" and match="A/bar" will succeed.

So, different question -- does the length of the path matter? What if
I did this:

<xsl:template match="A">
...
<xsl:template match="foo">
...
</xsl:template>
<xsl:template match="bar">
...

Is that going to gain me anything? will match="foo" execute faster than match="A/foo" if I know that I'm inside A?

I don't know if this is going to "gain" anything, but the problem is that the set of these three templates is not at all equivalent to the previous templates:

<xsl:template match="A">
...

There was no template matching "A" before -- this is something totally new -- most probably it will be useless.

<xsl:template match="foo">
...

This matches all "foo" nodes and not only "A/foo" nodes as before -- again this is something quite different.

<xsl:template match="bar">

The same as above.

If the templates now match different sets of nodes, then most probably the output of the transformation will change, therefore there must be concern about the correctness of the transformation -- not about the efficiency of an incorrect transformation.

=====
Cheers,

Dimitre Novatchev.
http://fxsl.sourceforge.net/ -- the home of FXSL

 

[Patrick TJ McPhee]

[...]

% What if I did this:
%
% <xsl:template match="A">
% ...
% <xsl:template match="foo">
% ...
% </xsl:template>
% <xsl:template match="bar">
% ...

It wouldn't work. You might want to try

<xsl:template match="A">
...
<xsl:apply-templates select="foo|bar" mode="A"/>
...

<xsl:template match="foo" mode="A">
...

You should use a processor which provides profiling information to compare your various attempts.

 

[David Andriana]

They are 13 pairs that each check the same condition, like this:

<xsl:template match="A/foo">
...
<xsl:template match="B/foo">
...
<xsl:template match="A/bar">
...
<xsl:template match="B/bar">
...

Use:

<xsl:template match="A/foo | B/foo">
...
<xsl:template match="A/bar | B/bar">
...

Yes, this will be faster.

You may want to reduce the number of sets calculated by XSLT (i.e. the total number of "match" clauses). No matter how complicated your XPath expression would be, it is always calculated one time only on each node, for the whole transformation.

That is, in your original XSLT, 26 node sets are calculated, even if not used, and no matter how many nodes there are in your XML source. But if you refactor, you will calculate only 13.

 

[Scott Raymond]

(Duane Morin) wrote:

Sonic's Stylus Studio v5 has a very nice XSLT Profiler (see http://www.sonicsoftware.com/products/additional_software/stylus_studio/index.ssp for a quick description). They have a demo version, so you might try it out for yourself. For what it's worth, I often prefer Stylus Studio to XMLSpy.

Scott-