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

RE: Are xsl:key's best going into the future?

Subject: RE: Are xsl:key's best going into the future?
From: "Michael Kay" <michael.h.kay@xxxxxxxxxxxx>
Date: Sat, 16 Mar 2002 10:06:19 -0000
sat key s
Firstly, Scott is talking about a possible future optimisation, rather than
one that exists in product today. Secondly, he only says it will be "as
fast", not that it will be faster. Thirdly, I would assume that he's saying
that "//page[@id=$id]" will be optimized to use the key *if a key has been
defined*. That's not a difficult optimization, and I've been thinking abobut
doing the same thing in Saxon (again, I don't do it today). What is far more
difficult is for the processor to decide automatically whether to create the
key in the absence of an xsl:key definition.

For the moment, keep using key() - it can give you vast performance savings,
and it will never be slower than the "//page[@id=$id]" form.

Michael Kay
Software AG
home: Michael.H.Kay@xxxxxxxxxxxx
work: Michael.Kay@xxxxxxxxxxxxxx

> -----Original Message-----
> From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of
> Robert Koberg
> Sent: 15 March 2002 18:58
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  Are xsl:key's best going into the future?
>
>
>
> ----- Original Message -----
> From: "Trevor Nash" <tcn@xxxxxxxxxxxxx>
> To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
> Sent: Friday, March 15, 2002 7:22 AM
> Subject: Re:  Are xsl:key's best going into the future?
>
>
> > On Fri, 15 Mar 2002 04:58:48 -0800, Robert Koberg wrote:
>
> > >I have heard a developer from Xalan say that he is working
> on making an
> > >operation like:
> > >
> > ><xsl:apply-templates select="//*[@id=$id]"/>
> > >
> > >as fast as:
> > >
> > ><xsl:apply-templates select="key('the-key', $id)">
> > >
> > In all cases?  I doubt it.
>
> here is the post I could not find last night:
> http://marc.theaimsgroup.com/?l=xalan-dev&m=101432516006719&w=2
>
> Scitt Boag from Xalan seems to think so (at least that is
> what I get from
> his post).
>
>
> >
> > These are functionally equivalent (assuming the right declaration of
> > 'the-key' of course!).  They are just two different ways of writing
> > the same thing, so any XSLT engine is free to use the same
> > implementation.  The reason most do not is that there is no
> algorithm
> > which is optimial in both the cases:
> > a) the expression is evaluated once
> > b) the expression is evaluated many times
> > So they tend to assume (a) for the XPath form and (b) for the key()
> > form.  In other words, by using XPath or key() you are telling the
> > XSLT engine more about the application, which it can then use to
> > produce a better optimised result.
> >
> > >[ I also asked if you would gain the same performance if you did
> something
> > >like:
> > ><xsl:apply-templates select="document($doc)//*[@id=$id]"> but no
> answer... I
> > >assume it is different?? ]
> > Probably the same, all you are doing is changing the context.
> >
>
> OK, I was thinking of the problems you get when in one
> document's context
> and you need to access another document's context. With keys,
> this is a pain
> in the butt.
>
> > >
> > >In fact, if you want to get the incredible performance
> gains from XSLTC,
> > >they:
> > >[ Xalan's XSLTC team -
> > >http://xml.apache.org/xalan-j/xsltc/xsltc_performance.html ]
> > >warn that you should not use keys.
> > >
> > >Should keys be avoided?
> > >
> > No.
> >
> > Think about it: if you can rewrite a key() expression as an XPath,
> > then the XSLT compiler can as well.  Its not actually very
> difficult.
> >
> > If they really do have a scheme where the XPath form is faster than
> > the key() form, then they should be doing the rewriting for you.
> > Otherwise, you are simply tying yourself to one processor.
>
> not faster, just equal.
>
> >
> > Its the same with any other programming language.  When
> it's new, you
> > can get significant performance gains by writing your code in a
> > particular form, because the compilers are none too bright.  As time
> > goes on and more optimisation algorithms are implemented,
> you get the
> > freedom to write the code the way it reads best, because
> the compiler
> > rewrites it for you into the most efficient form.
> >
> > Today, you make the choice between XPath or key() mostly on
> grounds of
> > performance, because XSLT compilers are relatively
> immature.  As time
> > goes on it should make less difference, so you get to use the form
> > which is easier to read.  I don't understand why the Xalan
> people seem
> > to be going in the opposite direction - perhaps you
> misuderstood them,
> > and this is a temporary situation.
> >
>
> It seems like the processor builders are starting in this
> direction. Just
> curious how far out in the future this will be??
>
> It is not hard to write keys and access them (unless you need
> to change
> documents in the template...), but it is easier to write
> '//page[@id=$id]'.
> If XSLT processors (I currently use Saxon) are moving in the
> direction that
> the easier to write syntax is just as fast as the more
> difficult to write
> keys, why use keys?
>
> best,
> -Rob
>
>
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
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.