One reason for the acceleration could be that only the first matching
rule within a pattern will be applied/evaluated. Roger, you might want
to check whether the number of failed-asserts and successful-reports in
the resulting SVRLs is the same for each scenario. It probably isn’t.
So putting all rules into a single pattern is not equivalent to having
distinct patterns for each rule.
Gerrit
On 22/12/2017 14:59, Michael Kay wrote:
>> /“Why is validation so slow?”/I wondered.
>>
>> I did some digging and discovered the reason for the slowness. Recall
>> that a Schematron schema is converted to an XSLT program. I looked at
>> the XSLT program that was generated for my Schematron schema. Here’s
>> what I found:
>>
>> <xsl:templatematch="/">
>> <xsl:apply-templatesselect="/"mode="M0"/>
>> <xsl:apply-templatesselect="/"mode="M1"/>
>> <xsl:apply-templatesselect="/"mode="M2"/>
>> <xsl:apply-templatesselect="/"mode="M3"/>
>>
>> …
>> <xsl:apply-templatesselect="/"mode="M29"/>
>> </xsl:template>
>>
>> That says: Start at the top of the XML document and process the entire
>> XML document, applying the template rules with mode M0. Then, start
>> all over at the top of the XML document and process the entire XML
>> document, applying the template rules with mode M1. And so forth.
>>
>> So, the entire 180 MB XML file gets processed 30 times.
>>
>> Eek!
>>
>> It’s no wonder that validation was so slow.
>>
>>
>
> It's interesting that this should make a big difference, but it's not at
> all inevitable. I would expect that the actual navigation (selecting
> child nodes) is very fast compared with the cost of evaluating match
> patterns and executing the template rules, and since each pass of the
> document is in a different mode, there should be very little cost for
> processing nodes that are effectively skipped. So the reasons for the
> slowness must lie a little deeper than you imagine. A lot will depend on
> the actual match patterns present in each mode. And of course, on the
> XSLT processor, since processors are likely to use very different
> algorithms for trimming the search space for pattern matches.
>
> And going into meta mode, as one does on xml-dev: It's quite common for
> a community to develop folk wisdom along the lines "don't do X, it's
> very slow" based on an experience like this that might (or might not!)
> turn out to have general applicability.
>
> With performance, the devil is always in the detail.
>
> Happy Christmas!
>
> Michael Kay
> Saxonica
--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
, http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler
