Subject: Re: Stylesheet optimisation From: Ray Cromwell <ray@xxxxxxxxxxxxx> Date: Mon, 6 Dec 1999 18:23:55 -0500 (EST) |
> 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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Stylesheet optimisation, Kay Michael | Thread | RE: Stylesheet optimisation, Kay Michael |
Re: mapping an XML file to another?, Dale Asberry | Date | XSL & servlets with SAXON, Patrick Cauldwell |
Month |