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(_dot_)fuller(_at_)ruminate(_dot_)co(_dot_)uk]
Gesendet: Montag, 10. Januar 2005 18:19
An: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--