[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Stylesheet optimisation

Subject: Re: Stylesheet optimisation
From: Ray Cromwell <ray@xxxxxxxxxxxxx>
Date: Mon, 6 Dec 1999 18:23:55 -0500 (EST)
xslt processor tuning
> We're talking about two different things. You're saying, I think, that there
> are XSLT stylesheets where it is possible to determine statically that they
> can be evaluated without keeping the whole tree in memory. That's almost
> certainly true. I'm saying that the transformation capability of such
> stylesheets is very limited, and that if you wanted to do serious
> transformations in which neither the source nor the result tree is all in
> memory at one time, then you would design the XSLT language rather
> differently. To take a trivial example, you wouldn't define <xsl:number> the
> way it is defined at present.

  I suspect this debate could go on endlessly trying to define the meaning
of what XSLT should be really be used for, or which styles are "limited"
vs "serious"  Personally, I've written all sorts of "serious" stylesheets
that I still think can be evaluated more efficiently. I don't want
to get into that debate. For instance, I'm not into print publishing.

  Nevertheless, all I'm suggesting is that XSLT processors have a long
way to go performance wise, and that the current crop of XSLT processors
are more like reference implementations, and are not "done" in terms
of how much performance can be squeezed out of the transformation
process.

  I can quite easily imagine techniques based on dynamic profiling,
hinting/tuning, input tree rotation, etc that can boost scalability
in addition to static optimization techniques. If I were running
a large website that was doing transformations, I would definately
want to be able to "tune" the processor for certain inputs, or
let it tune itself, the same way I would tune a DBMS.

  Other people might say, don't use XSLT. But the choice of
language is never based on pure performance alone. Tool
availability, standards support, developer availability,
opportunities for integration, etc are also things to
consider. If in the future, a huge amount of content is
XML+XSLT based, it's better to support it, even if it is
lower performance than a closed-proprietary version.

Are we really disagreeing? Do you think there is no possible
way to boost performance and scalability of so-called "serious"
stylesheets further than today's crop of processors?

Sincerely,
-Ray


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.