OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Rick Jelliffe's article on XSLT 1.0 performance

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"/>


<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.


On Wed, Feb 15, 2017 at 7:42 PM, Michael Kay <mike@saxonica.com> wrote:

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

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS