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.
—————
Eliot Kimber, Owner
Contrext, LLC
http://contrext.com
On 11/6/14, 12:09 PM, "Michael Kay mike(_at_)saxonica(_dot_)com"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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
--~----------------------------------------------------------------
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
--~--