[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

AW: [xsl] Stylesheet optimisation


Subject: AW: [xsl] Stylesheet optimisation
From: <christof.hoeke@xxxxxxx>
Date: Tue, 11 Jan 2005 09:40:18 +0100

Thanks to all for the hints.

I knew to get more or less very general ideas but some are actually quite
useful and I take a look into them. I do not have full access to the whole
system and it is beyond my control to change substancial stuff like which
processor or environment (cocoon?) to use but I can make suggestions, so even
general help is helpful.

@<prs/>: Maybe I put i wrong but all transformations are done server side


Thanks again,
Chris


> -----Urspr|ngliche Nachricht-----
> Von: Jim Fuller [mailto:jim.fuller@xxxxxxxxxxxxxx]
> Gesendet: Montag, 10. Januar 2005 18:19
> An: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Betreff: Re: [xsl] Stylesheet optimisation
>
> generic types;
>
> - always deliver any text based type thing from a server with
> gzip-encoding; apache has a module for doing this and
> instructions on how to define which mime-types/ext to deliver
> thusly...u will be amazed with the results.
>
> - if u must do client side transforms refactor your browser
> specific javascripts to manage transformations instead of
> loading stylesheets with an XML PI calling a stylesheet:
> there are more mechanisms in javascript for pre-loading or
> caching stylesheets (ex.
> http://www.perfectxml.com/articles/xml/XSLTInMSXML.asp?pg=2)..
.this of course complicates matters.
>
> - if you are interested in server side xslt performance, both
> in pre-publishing and dynamic server side xslt processing you
> can investigate compiled stylesheets...most of these
> technologies just convert your stylesheet into a java object
> (translets I think they were called...XSLTC being built into xalan)
>
> - pre publish as much as possible on the server to its final
> format....if things need to change, determine if the change
> is really dynamic or lets say you could schedule publishing
> every 15 minutes?
>
> - there are hardware appliances with XSLT processing built in
> mind these days, for all but the most serious situations I
> would imagine
>
> - like it or not, XSLT may not be the right tool for every
> publishing job....investigate refactoring using other
> techniques like SAX or perhaps your XML could be refactored
> to generate a more appropriate structure from source,
> designing out xslt transform steps.
>
> - make use of the nice timing mechanisms in SAXON to measure
> what parts of your stylesheet are slowing things down also
> depending on your xml size you can choose which tree model
> SAXON uses...which can have significant effects on speed.
>
> a few perf related tips at the XSL FAQ;
> http://www.dpawson.co.uk/xsl/sect4/N9883.html
>
> a recent perf article for .NET...very informative if this is
> your env
> http://www.fawcette.com/vsm/2005_02/magazine/features/tthangarathinam/
>
> if you live in a java app serv env I found this article
> somewhat useful
> http://www.sys-con.com/websphere/articleprint.cfm?id=412
>
> there is lots you can do to simplify your XSLT...though with
> no examples it hard to suggest anything.
>
> gl, Jim Fuller
>
> ps: add RAM/ more Processors/ get faster hard drives and use
> any other filesystem other then that provided by microsoft


Current Thread
Keywords