RE: key(). ( Re: Saxon VS XT )

Subject: RE: key(). ( Re: Saxon VS XT )
From: "Paulo Gaspar" <paulo.gaspar@xxxxxxxxxxxx>
Date: Mon, 7 Aug 2000 03:01:25 +0200
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@xxxxxxxxxxxxxxxx
> [mailto:owner-xsl-list@xxxxxxxxxxxxxxxx]On Behalf Of Paul Tchistopolskii
> Sent: Saturday, August 05, 2000 06:31
> To: xsl-list@xxxxxxxxxxxxxxxx
> 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


Current Thread