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

You are right. 
What I am looking for is to push implementer's options to end-users.
If a certain function has attributes that explicitly allows me to
delay its operation or run its operation in parallel to others in 
some cases. I would like to have an option.
This means the parser builder has to provide both ways of implementation.
What would the end-user benefit ?
The benefit could be depending upon the type of application/use the user
need not switch parsers to achieve this effect.
The other benefit is cutting down implementation/behavioral deviation by 
future Parser implementers/vendors with respect to 
parallelism/parallel processing.
Yes, 
You are right again that doing this to all functions is not at all ideal.
May be this can be done only to function(s) that take in parsed/un-parsed
internal/external data or node-sets.

regards

Raja



-----Original Message-----
From: Kay, Michael [mailto:Michael.Kay@softwareag.com]
Sent: Wednesday, March 13, 2002 4:40 AM
To: Raja Cherukuri; 'xsl-editors@w3.org'
Cc: Kay, Michael
Subject: 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 Saturday, 16 March 2002 07:36:00 UTC