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

Re: [xsl] how to estimate speed of a transformation

---

---

> David Tolpin wrote:
> >>XSLT is almost soley specified by expected result, not assuming any
> >>processing model  ...

Not me, David Carlisle wrote that. But I agree.

> First, some things will improve execution speed with almost any XSLT 
> processor.  Anything that avoids walking large parts of the input tree 
> multiple times is always good.  

The question is *what* avoids it. In the past messages I've tried to show
that constructs that may look as multiple walks through the input tree
are in fact not.

> Saving certain results in variables is 
> one way to do this.  Keys are often helpful.  Following the 
> suggestions of Michael Kay and Jeni Tennison (and others) on this list 
> will improve your stylesheets.

Not necessarily. While they are often helpful in particular cases, they
don't answer my questions; besides, sometimes (and quite often) solutions 
suffer from rapid execution time growth with some processors.

Grouping algorithms are a good example of that. Grouping algorithms
often proposed on this list exhibit quadratic complexity with a number of
processors, while are linear with more advanced ones. Even if linear,
they can be very slow with, say, jd.xslt, but fast with saxon (ten-fold).

> Second, some XSLT processors (DataPower's among them) are 10 times 
> faster than others.  Part of this is due to optimizations, and part is 
> due to raw technology.  These processors will be faster no matter what 
> stylesheets you write.

There is no raw technology that makes a*n^2 always smaller than b*n, and b*n always
smaller than c. (a,b,c are constants, n is the length of data). A processor written
in C is ten times faster than one written in Java for identity transform. The same
processor C is ten times slower than the other one when executes a grouping transformation
on a sequence of 10,000 elements.

> Finally, any stylesheet complex enough to have started this discussion 
> is probably too complex to analyze clearly.  Most commercial XSLT 
> processors (again, DataPower's among them) allow you to profile your 
> stylesheets during execution.  

No, a stylesheet that demonstrates differences between processors can be as short
as 30 lines long. And very simple. The whole point is that simple stylesheets
give the most differing results, not complex ones.

> It's the only way to know what's really 
> going on, and it will let you focus your improvements on those parts 
> of the stylesheet that need the most attention.

It is not what many great people thought. In fact, relying on debuggers and profilers
produces poor programs. A debugger or profiler should confirm hypotheses and assumptions,
not provide optimization data. The question is what to base hypotheses and assumptions on.

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---