[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Here's how to benchmark your XSLT program's execution time


Subject: Re: [xsl] Here's how to benchmark your XSLT program's execution time
From: "Abel Braaksma (Exselt) abel@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 7 Nov 2014 03:00:30 -0000

(I sent this from the wrong address and the thread is meanwhile advanced, but
perhaps the below is still somewhat applicable)

This may not yield the expected results, as order of evaluation is
undetermined. For instance, both $start and $end in most processors (assuming
you would make it cross-processor) will be evaluated only when they are
needed, I your case during the result-document evaluation.

Another optimization, not unheard of, is that variables can be eagerly
evaluated at start if the processor sees that all information needed for
evaluation is already there (*and* the variable is actually used somewhere
later).

Yet another optimization is that of functions: if called with the same
argument, they return the same result. This is, however, not always true, and
implementations have freedom for XSLT 2.0 to do this optimization (i.e.
resulting in uniquely created copies of nodes on each call to a function, or
in the same node each time a function is called with the same argument,
yielding different or the same node identities). In XSLT 3.0 the user is given
control on this by the attribute xsl:function/@identity-sensitive="yes|no".

The best way to prevent these optimizations from happening is to use function
call chaining and to get rid of the variables and use only the functions. But
it is less easy to make a general solution for that.

An alternative is to use fn:trace, if your processor is kind enough to output
the timestamp with each trace call. But again, the order of evaluation might
kick in.

As a coincidence, we were working on an extension for XSLT to tag instructions
to time them, something like a standard attribute:

<xsl:apply-templates ext:timings="on" />

But, unless such extension makes it into a standard, it is unlikely that it
will work cross-processor.

Cheers,
Abel

> -----Original Message-----
> From: Costello, Roger L. costello@xxxxxxxxx [mailto:xsl-list-
> service@xxxxxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, November 06, 2014 11:20 AM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: [xsl] Here's how to benchmark your XSLT program's execution
> time
>
> Hi Folks,
>
> So, you've got an XSLT program that is taking a long time to execute.
> You want to find out what part of the program is taking so much time.
> You need to insert some start/stop timers into your XSLT. Here's how to do
it:
>
> <?xml version="1.0" encoding="UTF-8"?> <xsl:stylesheet
> xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 xmlns:date="java:java.util.Date"
>                 version="2.0">
>
>     <xsl:output method="text" />
>     <xsl:output name="text-format" method="text"/>
>
>     <xsl:template match="/">
>         <!-- Start a timer -->
>         <xsl:variable name="start" select="date:getTime(date:new())"
> />
>
>         <!-- Do your XSLT processing -->
>         <xsl:apply-templates />
>
>         <!-- End the timer -->
>         <xsl:variable name="end" select="date:getTime(date:new())" />
>
>         <!-- Log the benchmarking results to a file, time-info.txt -->
>         <xsl:result-document href="time-info.txt" format="text-format">
>             start: <xsl:value-of select="$start" />
>             end: <xsl:value-of select="$end" />
>             diff: <xsl:value-of select="$end - $start" />
>         </xsl:result-document>
>
>     </xsl:template>
>
>     <xsl:template match="*">
>         <!-- Do something -->
>         <xsl:text>Hello World </xsl:text>
>         <xsl:value-of select="current-dateTime()" />
>     </xsl:template>
>
> </xsl:stylesheet>


Current Thread
Keywords