RE: key(). ( Re: Saxon VS XT )
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format