Re: RE: Re: XSLT and parallel processing (Was: RE: XSL

> > The modification that has to be done does not seem too complex:
> >
> > For every member of a sequence S of (sibling)
> > content-producing xsl instructions
> > (e.g. xsl:apply-templates) initiate its execution in a
> > separate thread. When all
> > threads have completed, serialize their outputs based on
> > their code position in the sequence S.
> >
> 
> I think if you did that, the synchronization overhead would certainly be too
> high. You'd be starting a thread to process each node in the source tree.
> The general approach is sound, but it needs to be applied more
> discriminatingly.

Fully agreed. This is why I was asking recently whether it wouldn't be useful to
have a linguistic construct in XSLT that allows the programmer to specify hints for
parallel execution. Another approach will use data obtained from profiling, or more
ambitiously, will try to dynamically estimate the "cost" of every specific
content-producer.

> Also, it doesn't tackle the challenge of doing the transformation in
> parallel with the parsing, tree building, and serialization.

This is so. But even this will be a huge first step.

Cheers,
Dimitre Novatchev.

__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list