xsl-list
[Top] [All Lists]

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

2007-11-10 03:42:05
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(_at_)saxonica(_dot_)com> 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/


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: 
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--