RE: [xsl] Wide Finder in XSLT --> deriving new requirements for efficiency in XSLT processors.

Subject: RE: [xsl] Wide Finder in XSLT --> deriving new requirements for efficiency in XSLT processors.
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Sat, 10 Nov 2007 10:15:25 -0000
> I have published this on my blog:
> 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

Current Thread