This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: Re: RE: Re: XSLT and parallel processing (Was: RE: XSL-List Digest V3 #1125)


Hi Dimitre

[Dimitri said]
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.

[Didier replies]
In fact, unless you have a multi-processor computer it doesn't really help
to parallelize the XSLT constructs. However, in the case of using the
"document()" function, this is tremendously useful. What I would like to get
is an XSLT processor that would fetch - in parallel - all the external
documents (i.e. get all the external documents referred by the document
function). Since, network latency is the major roadblock here, to process -
in parallel - the document fetching and transformation into infosets
operations would definitively increase the performance. I made several
experiments in Didier's lab and even shared these experiments with this
list's members. To process a document fetching in parallel, it suffice - for
the XSLT processor - to notice at parse time (of the XSLT document) all the
"document()" functions and to start fetching the documents in separate
threads, So, when the XSLT processing occurs, the XSLT processor won't stop
and wait at evey occurences of the "document()" function. The template
processing can start and be processed in one thread and the document
fetching in other threads. The gain? if you aggregate content from 10
documents and if it takes an average of 2 seconds to fetch the documents,
then

a) with parallel fetching: approx 2 seconds
b) without parallel fetching: 10 X 2 = 20 seconds

The gain is quite obvious. So I would start to improve XSLT in such ways
that it becomes a better tool for aggregating content. First step: better
management of network latency and include parallel document fetching in
current implementations.

Didier PH Martin


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]