[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Which is faster: count(/Document/A/B) eq 1 ... or ... /Document/A/(count(B) eq 1) ?


Subject: Re: [xsl] Which is faster: count(/Document/A/B) eq 1 ... or ... /Document/A/(count(B) eq 1) ?
From: Michel Hendriksen <michel.hendriksen@xxxxx>
Date: Thu, 20 Sep 2012 16:48:24 +0200

So use the one that is most clear and that will make maintenance easier;-)


On Thu, Sep 20, 2012 at 1:11 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> Execution speed is a property of the XSLT implementation, not a property of
> the language. You can't ask questions about performance without saying what
> processor you are interested in.
>
> With a trivial source document like this, it is very unlikely that any
> performance difference will be measurable.
>
> If there were a million B elements, some processors might (with either
> expression) count all the elements and then ask whether a million is equal
> to one. Other processors might (with either expression) stop at the second
> element and realize that the count is not going to be equal to one. So
> different processors might give very different performance from each other
> (with either expression), varying by a factor of a million.
>
> But then, if you parsed the source document containing a million B elements,
> it's likely that parsing the document would take a lot longer than counting
> the elements, so the performance difference including parsing cost might not
> be so big after all.
>
> If there were more than one A element, the two expressions would not be
> equivalent, so asking whether one is faster than the other is irrelevant.
> One of them will give the wrong answer.
>
> Assuming you know there will always be one A, I would think that the most
> consistent performance across processors would be achieved by writing
> not(Document/A/B[2]). Of course, there's still a possibility that a very
> naive processor would construct a node-set containing all the nodes in
> Document/A/B, and then select the second of these nodes. There are no limits
> to human stupidity.
>
> Michael Kay
> Saxonica
>
> On 19/09/2012 14:34, Costello, Roger L. wrote:
>>
>> Hi Folks,
>>
>> Consider this XML document:
>>
>> <Document>
>>      <A>
>>          <B>blah</B>
>>      </A>
>> </Document>
>>
>> Here are two XPath expressions to test that there is exactly one <B>
>> element in the <A> element (assume there is only one <A> element):
>>
>> 1. count(/Document/A/B) eq 1
>>
>> 2. /Document/A/(count(B) eq 1)
>>
>> Which is faster?
>>
>> Is there an XPath expression, besides the ones listed, that is even better
>> and faster?
>>
>> /Roger


Current Thread
Keywords