Re: [xsl] Saxon .Net API performance

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