This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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@ntlworld.com
work: Michael.Kay@softwareag.com

> -----Original Message-----
> From: owner-xsl-list@lists.mulberrytech.com
> [mailto:owner-xsl-list@lists.mulberrytech.com]On Behalf Of
> Robert Koberg
> Sent: 15 March 2002 18:58
> To: xsl-list@lists.mulberrytech.com
> Subject: Re: [xsl] Are xsl:key's best going into the future?
>
>
>
> ----- Original Message -----
> From: "Trevor Nash" <tcn@melvaig.co.uk>
> To: <xsl-list@lists.mulberrytech.com>
> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]