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