[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Rick Jelliffe's article on XSLT 1.0 performance

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

Re:  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]


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.