Subject: RE: [xsl] 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 |
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: [xsl] 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: [xsl] 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Are xsl:key's best going , Robert Koberg | Thread | Re: [xsl] Are xsl:key's best going , Jeni Tennison |
RE: [xsl] concat variable names, Michael Kay | Date | RE: [xsl] JDK14/JDOM: generating a , Oleg Tkachenko |
Month |