Re: [xsl] Are xsl:key's best going into the future?

Subject: Re: [xsl] Are xsl:key's best going into the future?
From: "Robert Koberg" <rob@xxxxxxxxxx>
Date: Fri, 15 Mar 2002 10:58:29 -0800
----- 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


Current Thread