| Profilo di DimitreXSLT: Riding the challen...BlogElenchiAmici | Guida |
|
29 ottobre AltovaXML claims to be 3 times faster than SaxonJ 8.7 ???This weekend I read about a claim made by Altova that their XSLT 2.0 processor was 3 times faster than SaxonJ 8.7. In particular, what they claim here is the following:
Michael Kay responds to these statements in his blog entry "Altova Mudslinging":
On the Questions and Answers page of Saxon Michael Kay provides his results comparing the performance of AltovaXML to Saxon:
So, it turns out that Saxon is about 10 times faster than Altova on the full W3C conformance tests. Here comes the fun part. Given the times reported the 4000 or so W3C conformance tests must be all small to medium-sized. As the beginning of wisdom is to call things by their right names, I ran some of my favourite transformations (from my FXSL library and Sudoku solver) on my 3-year old home (DELL Pentium IV 3GHz, 2MB RAM Windows XP SP2) PC. The results are below:
The "25min +" and "35min +" timings above actually mean that this was the time I was waiting for the AltovaXML2007-run - transformation to finish, before I decided to kill the process. While everyone is encouraged to perform their own tests and the results of the tests may vary, it seems that the above results are quite significant. To summarize the results:
UPDATE: Another person has run his performance tests. The results: "Saxon finishes this stylesheet in less then 3 minutes and consumes ~130 MB of RAM. For the most of the time Saxon utilizes only 70% of CPU -- disc is probably slower then Saxon ;-) As some proverbs go, and 21 ottobre A stylesheet to write XSLT code
func-standardStringXpathFunctions.xsl you have seen a lot of repetitive code like this:
<xsl:template match="f:string-join" <xsl:sequence select= <xsl:function name="f:string-join" </xsl:function> <xsl:function name="f:string-join" as="node()"> <xsl:sequence select= <xsl:function name="f:string-join" <xsl:sequence select=
You may have probably wondered how this code was generated for hundreds of standard XPath 2.0 functions. Until recently, the answer was: manually. A few days ago I had to provide the HOF wrappers for the only remaining group of XPath functions that didn't have one -- the various DateTime functions from the F & O spec. This time I decided to automate the generation process as much as possible. if one specifies a function in a xml file containing nodes like this: <f name="adjust-dateTime-to-timezone" <pdateTime type="xs:dateTime?"/> <fCode> then the full stylesheet module to create the HOF wrappers of the functions so specified is the following:
<xsl:stylesheet version="2.0" <xsl:output omit-xml-declaration="yes" <xsl:namespace-alias stylesheet-prefix="xxx" <xsl:template match="/"> <xsl:apply-templates/> </xxx:stylesheet> </xsl:template> <xsl:template match="f"> <xxx:template match="f:{@name}" <xsl:sequence select= <xsl:for-each select="*[not(self::fCode)]"> <xsl:variable name="vFuncCall" "('f:',@name, '(', " /> <xxx:sequence select="{$vFuncCall}"/> <xxx:function name="f:{@name}" <xsl:variable name="vFNode" <xsl:for-each select= <xsl:sequence select= <xsl:function name="fint:makeType" <xsl:function name="fint:makePartApp" <xxx:function name="f:{$pFNode/@name}" <xsl:for-each select= <xsl:variable name="vCurriedCall" <xsl:value-of separator="" select= <xxx:sequence select="{$vCurriedCall}"/> </xxx:function> </xsl:function> <xsl:function name="fint:makeFuncCode" <xxx:param name="{name(.)}"> <xsl:sequence select= </xsl:stylesheet> |
|
|