RE: Suggestion on parallelism / time-period trait for function( s)... .

I wonder if you could clarify? Are these remarks related only to core
functions defined in the XSLT and XPath specifications, or to they relate
also to user-defined functions?

As far as I can see, all the core functions are pure functions (they have no
side-effects) and therefore parallel execution is possible.

Specifying constraints on the execution performance would be difficult, I
think. Take the key() function as a typical example where some kind of
performance guarantees would be useful, for example, that key() should be
faster than a linear search of the document. Unfortunately this doesn't take
into account the cost of building an index. Would an implementation that
detected that key() was only used once, and therefore decided to do a linear
search to avoid the cost of building an index, be non-conformant with the
specification? Similarly, what if decided to discard the index because it
detected that performance was suffering through shortage of memory?

And if we specified performance expectations for functions, we would also
have to do so for other kinds of path expression. Should we mandate, for
example, that preceding::*[1] should have a performance that depends only on
the distance to the immediately preceding element, and not on the distance
from the start of the document? 

My own preference is to give implementors complete freedom to devise
efficient execution strategies, and to give users complete freedom to choose
an implementation that performs well for the tasks they need to perform.

Michael Kay



> Hi,
> It would be great if the function(s) implementation in XSLT 
> processor(s)
> can give mandates for 
> 	a) parallelism as yes/no.
> 	Reason:
> 	 1. This would allow XSLT parser implementor(s) to have unified
> behavior for function(s)
> 	    to a certain extent.
> 	 2. Allow parallelism would enhance/define performance 
> for functions
> like document(...).
> 	
> 	or	
> 
> 	b) time-period as linear/constant/etc. 
> 	( constant time could mean implementation must be parallel )
> 	Reason:
> 	1. Just like STL functions tell end-user the time 
> effects of using
> 	   different types of functions.
> 
> 
> regards
> 
> 
> Raja
> 
> 
>

Received on Wednesday, 13 March 2002 07:40:28 UTC