[Home] [By Thread] [By Date] [Recent Entries]

  • From: Rick Jelliffe <rjelliffe@a...>
  • To: Michael Kay <mike@s...>
  • Date: Wed, 15 Feb 2017 20:57:48 +1100

So do you know if anyone has implemented any optimizations using @as?

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 = "" as="xs:number"/>

or


<sch:rule context="person">
   <sch:let name="payrate"  value="//rate[$for = "" />

  <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 <mike@s...> wrote:

> On 15 Feb 2017, at 02:40, Rick Jelliffe <rjelliffe@a...> 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member