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

Re: XSLT Optimizer and Deployment

Subject: Re: XSLT Optimizer and Deployment
From: Karl Stubsjoen <kstubs@xxxxxxxxx>
Date: Tue, 16 Nov 2010 19:04:00 -0700
Re:  XSLT Optimizer and Deployment
Thank you for the tips!  I like the warning regarding stripping
white-space, although in a stylesheet I would typically avoid
white-space introduced by an editors linefeed or tab character from a
keystroke and rely only on white-space encoded values.
And yes, this is really not an exercise in performance (but again,
tips appreciated!) but in delivering clean, ready for production,
templates.  So essentially, guaranteeing that you don't leave behind a
big fat "hello, here i am" debug statement to the report.

Karl..

On Tue, Nov 16, 2010 at 4:36 PM, Liam R E Quin <liam@xxxxxx> wrote:
> On Tue, 2010-11-16 at 15:46 -0700, Karl Stubsjoen wrote:
>> I am writing an XSLT optimizer, basically stripping comments and extra
>> white-space from an XSLT document for production deployment.
>
> Have you measured the performance difference you get?
>
> Modern XSLT implementations (e.g. Saxon) already do quite a bit
> of optimization, at a much less superficial level.  You're
> likely to get more mileage adding "as' attributes, replacing =
> by eq, and replacing // with explicit paths (depending on the
> XML input, and on the XSLT processor - some of those suggestions
> depend on using XSLT 2, but if you're on XSLT 1 from 1998, get
> with the programme here ;-) )
>
> If you do decide to strip whitespace, make sure you don't do it
> inside xsl:text or inside templates containing text that's outside
> xsl:text elements.
>
>> My optimizer will perform a couple of additional steps:  set default
>> parameter values for production, make sure logging and other debug
>> steps are disabled, and so on...
>
> That may make more sense, but again distinguish between setting
> default values because they're correct for an environment, turning
> off debugging (might want debugging in production, no?) and removing
> possibly-sensitive information.
>
> Generally, logging surrounded by
>    <xsl:if test="$logBusinessDecisions">...</xsl:if>
> isn't going to slow thing down signficantly, and might be useful...
>
> In most cases I've seen, a small change in methods can give a much
> greater speedup (orders of magnitudes often) than removing spaces:
> e.g. using xsl:key to speed up access of frequently-used patterns,
> and checking code that uses idioms like // or preceding::* where not
> needed, as these can sometimes lead to O(n^2) or worse behaviour.
>
> Liam
>
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> Ankh: irc.sorcery.net irc.gnome.org www.advogato.org
>
>



--
Karl Stubsjoen
MeetScoresOnline.com
(602) 845-0006

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.