Re: Wide Finder in XSLT --> deriving new requirements

I too made a comment - I happen to have a hotmail address which I was
able to log-in as, but again the comment appears anonymous.

I agree that if a hint is necessary, then an extension attribute is
the right way of supplying it. But I would for the processor to be
able to do a good job without a hint. It's something I have intended
to research since 2001, but I think it will still be a couple of years
before I will be in a position to start on this.

On 10/11/2007, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>
> >
> > I have published this on my blog:
> >
> >
> > http://dnovatchev.spaces.live.com/Blog/cns!44B0A32C2CCF7488!385.entry
> >
> > There are two areas on which I would appreciate any feedback:
> >
> >    1. Finding a more efficient solution (there are such
> > RegExp gurus here!)
> >
> >    2. Discussing the ideas for lazy evaluation/streaming and
> > on constructs (a single extension function exslt:parMap() is
> > proposed) hinting possibilities for parallelization
>
> I managed to guess a username/password that worked(!) and made a comment,
> but it appears anonymously.
>
> I couldn't find a clear description of the problem - your link named
> "problem" seems to lead to a book.
>
> Most of the discussion suggests that the performance is going to be
> dominated by time taken to read the data off the disk. So I wouldn't have
> thought there is an enormous win for parallelization here. There's certainly
> more that can be done to reduce memory requirements by pipelining, though.
>
> I think you're right that parallelizing probably needs some kind of user
> hint in the stylesheet, but my instinct would be to make it an extension
> attribute so that the code will still work on any processor. There are
> certainly lots of opportunities. I had been thinking that probably the first
> thing to try would be
>
> <xsl:for-each select=...." xx:threads="4">
>
> and allocate the processing of the items in the input sequence to the N
> threads in a round-robin fashion. the challenge being of course how to
> marshal the output of the N threads, stitching it back together as a
> sequence in the right order, without using a lot of extra memory and
> creating a lot of extra coordination overhead. The ideal would be that if
> the input sequence is streamed, the output sequence should be streamed too.
>
> Michael Kay
> http://www.saxonica.com/