I have been thinking about the same thing for a while. I would like to have
a new option which only measures the transformation time. And let both the
new and the -diag option accept an optional integer as the number of
iterations.
Morris Kwan
XSLT Development
IBM Toronto Lab
Tel: (905)413-3729
Email: [EMAIL PROTECTED]
"Santiago
Pericas-Geertsen" To: Morris
Kwan/Toronto/IBM@IBMCA, Igor Hersht/Toronto/IBM@IBMCA
<Santiago.PericasGeerts cc:
<[EMAIL PROTECTED]>
[EMAIL PROTECTED]> Subject: Re: DO NOT REPLY [Bug
13560] - -XSLTC -DIAG is incorrect
10/23/2002 03:29 PM
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, October 23, 2002 3:00 PM
Subject: DO NOT REPLY [Bug 13560] - -XSLTC -DIAG is incorrect
> ------- Additional Comments From [EMAIL PROTECTED] 2002-10-23
19:00 -------
> We record the currentTimeMillis before the call
TransformerFactory.newTemplates
> () and after the call Transformer.transform(). The time reported by
the -diag
> option is the difference between the two. I did not make any change to
the
way
> the execution time is measured.
Perhaps it would make better sense to report both compilation time (before
TransformerFactory.newTemplates() until after Templates.newTransformer())
and execution time (before and after Transformer.transform()). XSLT
processing on the server side, where performance really matters, is
typically done by compiling once and running multiple times. Aggregating
the
two numbers does not really help a user decide which processor is better
for
a particular stylesheet.
In fact, I suggest the addition of #iterations to -DIAG to eliminate the
huge constant factor incurred on the first iteration as a result of things
like class loading (and also to see the effects of the JIT compiler). The
-n
option of XSLTC's Process does exactly this.
My $0.02.
-- Santiago
