Re: Here's how to benchmark your XSLT program's execut

In my case, the process is being run through the DITA Open Toolkit, which
makes it hard (or at least inconvenient) to run the transform under a
profiler or from within Oxygen. So easier to just emit timing messages.

At least for the processing I'm doing, the timing messages seem to
accurately reflect the specific processing I'm focusing on (the time taken
by one apply-templates applied to a single input file. Also, I'm only
interested in relative values, not absolute, so it's enough to know that
file X takes 8 units of time where the others take 0.5 units.

So for my purposes this use of Java Date is a quick and easy way to do
some crude profiling in the context of a larger tool chain.

Cheers,

E.
bbbbb
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com




On 11/6/14, 12:09 PM, "Michael Kay mike@xxxxxxxxxxxx"
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>
>> What does this tell you?
>
>Very little, unless you are very careful and know exactly what you are
>doing. For example, the cost you measure might include "side-effects"
>such as building an xsl:key index or evaluating a global variable. There
>is so much opportunity for an XSLT processor to do things eagerly or
>lazily, (or increasingly, in parallel), that any numbers for the cost of
>evaluating individual templates need very careful interpretation.
>
>But the numbers do give a clue where to look first for performance
>problems. I had a problem stylesheet recently where the Saxon profile
>showed 99% of the time being spent in one template rule. The problem code
>wasn't actually in that rule, it was in a match pattern of another rule
>that was being invoked by an apply-templates call in the "expensive" rule.
>
>Michael Kay
>Saxonica