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]

(e-mail address removed) (Duane Morin) wrote in message

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-