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
gerrit.imsieke@le-tex.de, 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
____________________________________________________________ ___________
XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.
[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php