Re: Practical Suggestion for XSLT Performance Improvement

Subject: Re: Practical Suggestion for XSLT Performance Improvement
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Mon, 11 Oct 1999 11:24:34 +0200
Clark C. Evans <clark.evans@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 10 Oct 1999, Oren Ben-Kiki wrote:
> > Actually, it is worse then that. The war is lost if you use
> > select="$complicated-path" _anywhere at all_, even in the humblest
> > <xsl:value-of>. You also get in trouble by using multiple
> > <xsl:apply-templates> on the same input tree fragment
>
> Oren, thanks for responding!

Back from my three weeks military duty for this year :-)

> To have one-pass stream
> processing (XSLTS), extreme (but not unreasonable) limits
> must be placed on the stylesheet:

Right. Defining them is a tricky issue. What you described is a bit too
restrictive; you can get away with some forms of match clauses for
<xsl:apply-templates/> and <xsl:for-each/> - refering just to descendents of
the current node, for example. Specifying multiple calls in the same
template would be prohibited, except for matching on attributes. Or
something. In fact, this is complex enough that if (when...) the need for
streaming XSLT becomes pressing, it would be worth while to define this
formally - either by the W3C or by someone else.

The cause of the problem is that XSLT started with a vision of a language
powerful enough to do "most" transformations but simple enough to allow all
sorts of automatic reasoning/optimizations implementation techniques. The
first requirement has resulted (for good and sufficient reasons) in adding
enough features so that it became Turing complete. Therefore, second goal is
lost _in the general case_. On the other hand, some restrictions which
originated from this second goal were not lifted - in particular, matching
on result tree fragments. This means that while you can do "anything" in
XSLT, sometimes you have to write pretty convoluted code to achive it.

For example, you _can_ pass data from one template invocation to another.
You just need to encode it as a string instead of as a result tree fragment.
I posted a sample to this mailing list a while back. It was an XSLT program
which computed solutions to the N-queens problem. Admittedly people will use
such code only as a last resort. The benchmark for sums over a really large
document might be a good example for a place where it might be necessary/

Your named-pipe mechanism is one possible way to remove the remaining
restrictions. However, as I see it, there's a much minor change to XSLT
which would achieve the same effect - removing the restrictions on matching
on result tree fragments. It seems to me that anything which can be done
using named pipes can be done as easily using such fragments. Unless you
have a counter example?

> Perhaps there are two ideas here, the first one
> describing a limited subset of XSL for stream
> procesors

Something which is probably wothwhile...

> and the second one is more of a
> "network of stream processors" working togehter
> in a generative manner.   So, mabye it is not
> at all appropriate to build in a "return-pipe"
> mechanism, but it may be more appropriate to
> describe a "reaction document" (to use Stefano's
> idea in the Coccon project), which documents a
> collaboration of stream processors working together
> in a recursive manner.  Then, some framework would
> have to be built which animates this larger structure.

Which simply isn't XSLT as we know it. It is impractical to switch tracks at
this very late stage of the game. After all, it isn't a draft now - it is
already a proposed recommendation.

> Does this make sense?

Actually it makes perfect sense to me. My master thesis has dealt with a
side-effects free, actors-like data-flow language which I still feel is the
"one and only right way to write non-sequential code". Think of it as the
framework you mentioned. It is a beautiful concept... but it never made it
into the mainstream. Yet another casualty of Moore's law...

Have fun,

    Oren Ben-Kiki



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


Current Thread