Does 'match' cost performance?

**Dimitre Novatchev** · Jul 20 '05, 06:10 AM

Re: Does 'match' cost performance?

"Duane Morin" <dmorin@morinfa mily.com> wrote in message
news:554f29fd.0 309131732.5df1b b34@posting.goo gle.com...[color=blue]
> 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.)[/color]

One could refactor these as:

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

and

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

[color=blue]
> 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?[/color]

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

[color=blue]
>
> Duane[/color]

**Duane Morin** · Jul 20 '05, 06:10 AM

Re: Does 'match' cost performance?

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

dmorin@morinfam ily.com (Duane Morin) wrote in message news:<554f29fd. 0309131732.5df1 bb34@posting.go ogle.com>...[color=blue]
> 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[/color]

**Dimitre Novatchev** · Jul 20 '05, 06:10 AM

Re: Does 'match' cost performance?

"Duane Morin" <dmorin@morinfa mily.com> wrote in message
news:554f29fd.0 309140746.7dbcd 7dd@posting.goo gle.com...[color=blue]
> 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?[/color]

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:

[color=blue]
> <xsl:template match="A">
> ...[/color]

There was no template matching "A" before -- this is something totally
new -- most probably it will be useless.
[color=blue]
> <xsl:template match="foo">
> ...[/color]

This matches all "foo" nodes and not only "A/foo" nodes as before -- again
this is something quite different.
[color=blue]
> <xsl:template match="bar">[/color]

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** · Jul 20 '05, 06:10 AM

Re: Does 'match' cost performance?

In article <554f29fd.03091 40746.7dbcd7dd@ posting.google. com>,
Duane Morin <dmorin@morinfa mily.com> wrote:

[...]

% 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.

--

Patrick TJ McPhee
East York Canada
ptjm@interlog.c om

**David Andriana** · Jul 20 '05, 06:10 AM

Re: Does 'match' cost performance?

Duane Morin <dmorin@morinfa mily.com> wrote:
[color=blue]
> 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">
> ...[/color]

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.

--
David

**Scott Raymond** · Jul 20 '05, 06:11 AM

Re: Does 'match' cost performance?

> dmorin@morinfam ily.com (Duane Morin) wrote in message
news:<554f29fd. 0309131732.5df1 bb34@posting.go ogle.com>...[color=blue][color=green]
> > 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[/color][/color]

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-

Does 'match' cost performance?

Does 'match' cost performance?

Comment

Comment

Comment

Comment

Comment

Comment