Re: [xsl] How to output the start execution time and the end execution time?

["Wolfgang Laun wolfgang.laun@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Yeah, many ifs and buts...

We all know the joke of the astronomer, physicist and mathematician
travelling thorugh Scotland?

Anyway, if you apply /usr/bin/time on a selection (according to your
fancy!) of input data, running a transformation using one specific XSLT
processor (version) on one particular CPU, you can report those times. And
that's it - at least in my (very conservative) opinion.

-W



On 6 September 2014 19:47, Abel Braaksma (Exselt) abel@xxxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Hi Wolfgang,
>
> See my latest reply in this thread, about using accumulators, which gets
> rid of the issues related to order of execution. Also, in Dimitre's mail,
> at the bottom, he noted that you cannot be sure of what you are measuring,
> because of the undefined order of (parallelized?) execution.
>
> Alternatively, I think you might be able to rewrite Dimitre's example
> using xsl:next-match, to force a proper order of execution. Something like
> this (not tested):
>
> <xsl:template match="/" priority="10">
>     <!-- get time, this is start time-->
>     <xsl:next-match />
> </xsl:template>
>
> <xsl:template match="/" priority="9">
>     <!-- "normal" processing -->
>     <xsl:apply-templates />
>     <xsl:next-match />
> </xsl:template>
>
> <xsl:template match="/" priority="8">
>     <!-- get time, this is end time -->
> </xsl:template>
>
> But I am not 100% sure it will get rid of all possible optimizations.
> I.e., when the processor sees the fn:doc calls, it might try to pre-process
> them while at the same time already doing template processing. I don't
> think any processor optimizes so strongly, but that may be just a matter of
> time.
>
> Cheers,
>
> Abel Braaksma
> http://exselt.net
>
> > From: Wolfgang Laun wolfgang.laun@xxxxxxxxx
> >Sent: Saturday, September 06, 2014 7:10 PM
>
> > given that the call to an external timepiece delivers the
> > wallclock time: how can one be sure that a call near the
> > top of the  XSLT program is executed first, e.g., before
> . accessing the main document? And how can one be sure that
> > a call near the end of the program is the last thing the
> > program does, e.g., even after writing/serializing everything
> > and flushing all buffers?
>
> > Not really knowing what one measures? Not being sure how the
> > data influences the result?