This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: key(). ( Re: Saxon VS XT )
- To: <xsl-list at mulberrytech dot com>
- Subject: RE: key(). ( Re: Saxon VS XT )
- From: "Paulo Gaspar" <paulo dot gaspar at krankikom dot de>
- Date: Mon, 7 Aug 2000 03:01:25 +0200
- Reply-To: xsl-list at mulberrytech dot com
I think I understand your point.
What helped me understanding is that I have been playing
with the idea of using XML indexing techniques in order
to be able to perform XSLT over very large XML streams
with a low memory footprint.
Well, XML element and attribute names are better indexed
using hash tables... but what to index?
That requires analyzing the XSLT to process in order to
decide the indexing strategy.
Funny how this is the similar to what you are talking
about: by analyzing the XSLT a XSLT engine should be
able to decide what hash tables/indexes to build for a
fast execution of the transformation.
Before thinking on this the last couple of weeks, key()
looked more important, but now, after your remark, it
doesn't sound SO important any more.
However, I can imagine there will be situations where
you really get it faster with an hint. No analyzer will
get all expressions that can get faster with an index.
This analyzer limitation has to do with indexing being
a delicate matter when maximal performance is the
target: both indexing too less and indexing too much
are a waste of time.
My guess is that a generally efficient engine will be a
bit conservative on indexing and sometimes index too
less. Using key() to force indexing something could
help reaching maximal performance in such situations.
(Similar to SQL hints, isn't it?)
> Even your words about XT-fanatizm are reasonable
> ( and I agree that I'm sometimes too emotional when it
> comes to tools and I wish all my opponents forgive me
> for this ) ,
Not an opponent here. To have fun at work one must be
enthusiastic about it. Problem is when enthusiasm about
something blunts peripheral vision.
Actually, it looks that it was NOT blunting your
peripheral vision but it was blunting the clarity of your
posting:
- I, at least, was getting distracted from the
importance of your arguments on key() because of your
arguments on XT.
Anyway, I downloaded XT after reading your posting. Your
enthusiasm on XT had that effect.
=:o)
Have fun,
Paulo Gaspar
P.S.: Of course that indexing a big XML stream would
require temporarily storing it on disk, all or only
meaningful parts - when XSLT analisys would allow to
evaluate these.
> -----Original Message-----
> From: owner-xsl-list@mulberrytech.com
> [mailto:owner-xsl-list@mulberrytech.com]On Behalf Of Paul Tchistopolskii
> Sent: Saturday, August 05, 2000 06:31
> To: xsl-list@mulberrytech.com
> Subject: key(). ( Re: Saxon VS XT )
>
>
>
> > I think he was kidding.
>
> Not realy. The point is that I think there is almost no
> need in 'special support of hashtables' in XSLT, because :
>
> 1. node-set itself is already kind of hashtable.
> 2. I don't think that when making <xsl:value-of select="./foo">
> the underlying engine code enumerates each child
> with if ( string.equals("foo") )
>
> I mean that XSLT already has some 'built-in' mechanizms
> which are very close to "hashtable support".
>
> Even your words about XT-fanatizm are reasonable
> ( and I agree that I'm sometimes too emotional when it
> comes to tools and I wish all my opponents forgive me
> for this ) , unfortunately the problem is that this is
> not the case with key().
>
> After spending some time with Sebastian's sample
> I still think that key() is not a good thing ( I'm 100% sure
> than document() with 2 parameters is also not a good
> thing ), because it results in the code which is hard for
> reading. Try looking inside Sebastian's test6.xsl and try
> to understand what the code does *not* looking into the
> .xml file. I think it will take some time, no matter how
> experienced you are with XSLT. It is very much like
> that 'select bla-bla from dual' instead of simple
> 'autoincrement' ;-) By the way - Sebastian's code is
> *very* clear. It is the 'key()' stuff which is messy.
>
> Because the thread become hotter than it should be, today I
> have spent some time preparing the simplistic solution
> ( at the moment I have 2 ) to show that there is
> no need in key() in test6.xsl. There are some surprizes,
> because I suddenly found that for some reason some Xpath
> expressions suddenly become extremely slow ( up to five-ten
> times slower ) when I add some simple predicate that should
> *not* have such impact.
>
> I'm now investigating what happens with latest version of SAXON
> and XT and if my kids will not cry too much till the weeekend I think
> that I'l get a 'simple workaround' for test6.xsl much faster than
> in 2 weeks. 2 weeks is to solve the 'entire' problem ( the 'entire'
> problem is the weakness of hierarhical model in comparsion
> to relational.)
>
> Rgds.Paul.
>
> PS. I suggest to look at Sebastians 'tests' I think it is a pity that
> the task which is *trivial* if placing it into relational model becomes
> so horrible when trying to 'do it all with 'XML-only' way' .
> Really. Even my old and ill PXSLServlet can provide
> all those views for the cost of nothing, just a bunch of 'order by's' -
> and no problem *at all*. But because saying to Sebastian
> "Sebastian, you should start using my tool" is something I
> don't think I'l ever say - I'm now trying to find something simpler ;-)
>
> PPS. key() is a 'road-sign' people are using to speed-up
> the processing of some things. This is a bad thing
> when compiler requires *user* to provide such a roadsign.
> Right?
>
> Or there is some other meaning behind key() ? What is that
> meaning ? ( Maybe I'm stupid, but the explanation with the
> words 'hashtable support' is not the explanation to me at all.
> Nodeset itself is a hashtable. In XML every node is a
> hashtable-of-hashtables. The entire XSLT is about processing
> huge hashtables ( AKA XML files AKA node-sets )).
>
> > > >Poor C, ( and Pascal ) they had no build-in hashtable support.
> > > Red herring
> > > You don't need built-in support to create a hashtable in C
> it's so simple.
> > >
> > >
> > > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
> > >
> >
> >
> > XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
>
>
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
>
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list