Re: XSLT use cases; data-centric to document-centric

On Tue,  8 Feb 2005 10:35:40 +0100, Peter Gerstbach <peter@xxxxxxxxxxxx> wrote:
> Zitat von David Carlisle <davidc@xxxxxxxxx>:
> 
> > One of XSLT's great strengths is it allows
> > you to seemlessly mix these two styles and a typical stylesheet is
> > somewher in between (because a typical document is neither all "data"
> > nor all "document".
> 
> I'm often surprised that there are always so many different ways how to solve
> one problem with XSLT. I'm able to solve most of the problems, but when I look
> at the mailing list, I can see that there always better solutions out there...
> :)
> 
> When comparing performance I found out, that xalan and saxon perform bad when
> there is only on big template. When the template is very large, saxon
> even ends
> up in an StackOverflowError.
> 


It is not wise to make such generalisations.

An XSLT processor is just running the code that *you* wrote. It is
very probable that the reason for the inefficiencies is in your code.

Before saying:

     "This stupid XSLT processor handles my code very inefficiently
and even crashes"

one must be sure that:

      "my code implements an efficient algorithm and is provably correct"

In the case you describe we have somewhat opposite evidence -- the
fact that *more than one* XSLT processor exibits the same behaviour
when running your code most probably means that the problem is exactly
in your code and not due to any individual XSLT processor.

A claim like that can be reasonable only if the code is run
efficiently on a set of XSLT processors and is inefficient only on a
specific XSLT processor.

Is this your case or not?

Cheers,
Dimitre Novatchev.

P.S. 
I vaguely remember reading how a O(N) algorithm implemented in Basic
on a very slow calculator runs faster than an O(N^3) algorithm
implemented in C and running on a very fast computer. This was the
problem of finding the subsequence with maximum sum, with 5 different
algorithms discussed in Jon Bentley's brilliant book "Programming
Perls".