Subject: Re: [xsl] Wide Finder in XSLT --> deriving new requirements for efficiency in XSLT processors. From: "Colin Adams" <colinpauladams@xxxxxxxxxxxxxx> Date: Sat, 10 Nov 2007 10:41:34 +0000 |
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/
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] Wide Finder in XSLT --> d, Michael Kay | Thread | RE: [xsl] Wide Finder in XSLT --> d, Michael Kay |
RE: [xsl] Wide Finder in XSLT --> d, Michael Kay | Date | Re: [xsl] Accessing context from xs, Mukul Gandhi |
Month |