Subject: Re: [xsl] Saxon .Net API performance From: Andrew Welch <andrew.j.welch@xxxxxxxxx> Date: Thu, 2 Sep 2010 10:35:13 +0100 |
> Apart from grouping, what features of XSLT 2.0 can I take advantage of to improve performance? Hmm this should really be a separate thread, but some of the things off the top of my head that make 2.0 sooooo much better than 1.0 (not necessarily confined to performance): - xhtml output method: no need for any messing around to prevent tag minimisation, and produces well-formed xml output to allow post-processing - atomics: if you use array-like temporary trees, they can be replaced with sequences of atomics (this does give a large performance boost) - typing: parameter and return types can be atomics instead of nodes, no need for node creation and then getting the string value (again a boost here) - functions: where these are more appropriate than named templates, it can really tidy up your code... (for example f:foo($bar, $baz) vs <xsl:call-template name="foo"><xsl:with-param...... ) - tunnelled parameters: another godsend for anyone that has done this manually before - regexs, analyze-string etc - The ability to process non-xml files (for example using unparsed-text() to process csv files) - Standalone transforms: you can just "run" a 2.0 stylesheet and it can pull in any data itself. - XPath 2.0 functions: http://www.w3.org/TR/xpath-functions/ - XPath 2.0 inline conditionals: instead of a cumbersome choose/when for a simple if/then/else you can now do a simple if/then/else for example: select="if ($foo) then $bar else $baz" - Result validation: you can validate during development, and toggle it off for prod... - Lastly, but probably the best thing: 2.0 is "fail early" while 1.0 is "don't fail". With XSLT 1.0 bad data or some mistake still generates output (which you only find out about later), whereas in 2.0 the transform will fail. There are plenty more that I've forgotten. The main performance increase can come from reducing the overall processing pipeline - are there pre- and post-processing steps for tasks that could be done directly in the XSLT? Do you currently call out to extension functions? Those tasks could be written in stylesheet instead, making debugging and deploying the XSLT far simpler. Is there a load of effort surrounding the existing 1.0 transform? Often with 2.0, the code simply needs to run the transform, simplifying the whole process. -- Andrew Welch http://andrewjwelch.com
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Saxon .Net API performanc, Michael Kay | Thread | RE: [xsl] Saxon .Net API performanc, Merrilees, David |
Re: [xsl] Creating exception in pro, Michael Kay | Date | RE: [xsl] Moving elements during id, Praveen Chauhan |
Month |