Re: [xsl] xsl:for-each-group using multiple threads?

["David Rudel fwqhgads@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Note that, depending on the particular structure of your problem, you
can modify this tack to make it streamable as well, if that is of
interest. The performance hit might be rather significant, though.

On Tue, Jan 27, 2015 at 3:09 PM, David Rudel <fwqhgads@xxxxxxxxx> wrote:
> I don't know if this is at all helpful because it requires two passes
> through the data, but...
>
> You can first create a map holding the grouping information
> (map(xs:integer,xs:item*)) with 1 mapped to the first group, 2 mapped
> to the second group, etc. Then you can processes these groups using
> <xsl:for-each>, which supports multi-threading:
>
> <xsl:for-each select="saxon:sort(map:keys($my.grouping.map)))"
> saxon:threads="8">
> <xsl:variable name="group" select="$my.grouping.map(current())"/>
> ....
> <xsl:for-each/>
>
>
>
> On Tue, Jan 27, 2015 at 11:20 AM, Marc Kupietz kupietz@xxxxxxxxxxxxxxx
> <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> 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
>> 
>
>
>
> --
>
> "A false conclusion, once arrived at and widely accepted is not
> dislodged easily, and the less it is understood, the more tenaciously
> it is held." - Cantor's Law of Preservation of Ignorance.



-- 

"A false conclusion, once arrived at and widely accepted is not
dislodged easily, and the less it is understood, the more tenaciously
it is held." - Cantor's Law of Preservation of Ignorance.