Multi-threading is never cheap, because of the amount of testing needed to get
it right, and the cost of diagnosing bugs. Come to XML Prague in February where
I am speaking on the topic...
But yes, it would be nice. And I've recently made changes to implement some of
the multi-threading support in a more generic way, which might make the code
more reusable.
A really good implementation of multi-threaded grouping would not only process
the groups in parallel with each other, it would process a group in parallel
with building the group, at least in the case where the processing is streamed.
But streamed grouping is pretty hairy already, streamed multi-threaded grouping
is the stuff of sleepless nights.
Michael Kay
Saxonica
mike(_at_)saxonica(_dot_)com
+44 (0) 118 946 5893
On 27 Jan 2015, at 10:20, Marc Kupietz kupietz(_at_)ids-mannheim(_dot_)de
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Unfortunately, xsl:for-each-group does not seem to support the
saxon:threads attribute. Can anyone think of a workaround to split the
processing of groups among multiple threads without causing a lot of
overhead?
If there is no such workaround, wouldn't it be a nice (and cheap?)
feature to add saxon:threads support to xsl:for-each-group?
I think such a feature would in many applications allow for a better
control over the thread-overhead/work ratio when using multiple
threads.
Marc
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--