Re[4]: Aggregate

Subject: Re[4]: Aggregate
From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
Date: Tue, 14 Nov 2000 10:27:57 +0000

>> So, to find the maximum of the 'in' elements, use:
>>   in[not(parent::TIME/in &gt; .)]
> But I'd express caution, certainly for large node-sets. This is likely to be
> an O(n-squared) solution (it certainly is in Saxon). Doing an XSLT sort and
> extracting the first or last element is likely to be O(n*log(n)). Doing a
> recursive walk of the node-set as described in XSLT Prog Ref page 171 is
> likely to be O(n).

Good point.  Would it make any difference if the XPath was:

  in[not(parent::TIME/in &gt; .)][1]

Would the extra positional predicate make the processor (or Saxon at
least) stop once it found the first instance, and therefore be more
efficient?  Or what about a mix:

<xsl:template match="in" mode="find-max">
  <xsl:variable name="greater"
                select="following-sibling::in[. &gt; current()][1]" />
    <xsl:when test="$greater">
      <xsl:apply-templates select="$greater" />
    <xsl:otherwise><xsl:value-of select="." /></xsl:otherwise>

I tend to assume that XPaths are always going to be more efficient
than using equivalent XSLT instructions because processors have a
greater opportunity for optimising XPaths, but I guess that's a false
assumption, especially where there are processor optimisations on



Jeni Tennison

 XSL-List info and archive:

Current Thread