Re: [xsl] xpath // query

Subject: Re: [xsl] xpath // query
From: "Siarhei Biarozkin" <sberyozkin@xxxxxxxxxx>
Date: Wed, 24 Apr 2002 13:37:56 +0100
Andrew,
Here's my guess:
"A//B//C" should be faster than "A//C", because with the former xpath
expression the processor will first look for all "B" descendants, thus
filtering out the elements which don't have "C" as their descendant ; with
the latter xpath, it will check every descendant-or-self on whether it has a
child C or not
Regards
Siarhei Biartozkin


----- Original Message -----
From: "Andrew Welch" <awelch@xxxxxxxxxxxxxxx>
To: "Xsl-List (E-mail)" <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, April 24, 2002 12:34 PM
Subject: [xsl] xpath // query


>
> Hi list,
>
> If I know that the element I am looking for will have a two certain
> ancestors, but an unknown number of elements in between, can I improve the
> xpath to reach the element by including the middle element?
>
> For example, is:
>
> select="A//C"
>
> any different to:
>
> select="A//B//C"
>
> when I know that <B> is *guranteed* to be there (both select the same
> nodes).  By adding the test for <B>, will it make the selection any
faster?
>
> After thinking for a while, Im guessing it makes no difference to the
> selection time as the same number of nodes still need to be traversed.
> Theoretically, it may be slower as it involves an extra test.  Is this
> correct?  (or too insignificant to worry about)...
>
> cheers
> andrew
>
>
>
>
>
>
>
>
>
>
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.350 / Virus Database: 196 - Release Date: 17/04/2002
>
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread