Re: [xml-dev] Rick Jelliffe's article on XSLT 1.0 performance

I appreciate that @as can be valuable for software engineering reasons: clarity and strict typechecking of course.  Good things.

For Schematron I am still not sure whether it would be better to have

<sch:rule context="person">

   <sch:let name="payrate"  value="//rate[$for = current()/@class]"  as="xs:number"/>

or


   <sch:let name="payrate"  value="//rate[$for = current()/@class]"  />

  <sch:assert tes"number(payrate)" >The payrate should be a number</sch:assert>

I mean, if  xslt:variable/@as is not used for any significant optimizations, then isn't it just an assertion about type in which case the appropriate markup is should be an explicit assertion, not a type statement.

Cheers

Rick

On Wed, Feb 15, 2017 at 7:42 PM, Michael Kay <[email protected]> wrote:

> On 15 Feb 2017, at 02:40, Rick Jelliffe <[email protected]> wrote:
>
> Does anyone have any benchmarks on how much @as can improve performance, or any tips on which particular cases it helps.  I had kinda written it off as one of these theoretical improvements that never really pays off enough to be much use.
>

I don't have any numbers I can share, and the effect is going to be very variable across stylesheets.

The main benefit of using @as attributes isn't performance, it's maintainability - your code becomes more readable and errors are reported earlier, often at compile time.

The performance effects will usually be fairly marginal - the system doesn't have to do so much run-time checking, and it can make earlier decisions on things like what arithemetic or comparison operator to use. Occasionally, though, the availability of type information opens the door to a much bigger optimization. To take an example, if you have an xsl:choose with conditions like test="$x = 3", then if you know that $x is a single atomic value, you also know that the conditions $x=3 and $x=4 are mutually exclusive, so you can implement the xsl:choose with a hash lookup. If $x can be multi-valued then that isn't the case. Another example: given $x/price, if you know that $x is a single node then you know that you don't have to sort the result into document order and eliminate duplicates.

Michael Kay
Saxonica