Subject: Re: [xsl] Ordering of Blocks based on Input/Output From: Francis Norton <francis@xxxxxxxxxxx> Date: Thu, 10 May 2001 00:06:07 +0100 |
Hi Jeni, Jeni Tennison wrote: > > But my point about set:difference() was that while with the former > paths the processor is honour-bound to go through *every* node in > $left to work out whether it's the $next node or not, with > set:difference() it could stop checking at the point that it found the > $next node, knowing that the rest of the nodes in $left couldn't be > the $next node. That means it would visit less nodes, or at least > could do if it were doing some lazy evaluation or something. > Yes. Unless the processor recognises one of the two cheat syntaxes as being set:difference() and optimises it - in which case they're hardly likely to have left their real set:difference() function un-optimised. > Plus of course anything that's built in to the processor is going to > be faster than constructing an equivalent XPath for it. > Yes. Comparing two node-sets, both probably held in document order? My guess is that this has to bring the number of comparisons down from something like (m*n) to something like (m + n). Could be even less - consider doing a binary search to see if a singleton node is in an ordered node-set. There's probably some well-known computer science algorithm for doing both - anybody? Francis. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Ordering of Blocks based , Jeni Tennison | Thread | RE: [xsl] Ordering of Blocks based , Michael Kay |
[xsl] XSLT Generators / xsl:for-eac, Kyle D. Morton | Date | Re: [xsl] XSQL/NAMESPACE, Steve Muench |
Month |