What is the fastest XSLT processor on the planet?
Why just not benchmark...
As input XML lets take four volumes of War and Peace of Lev Tolstoy from www.lib.ru, copy/paste them into Word, and save as one Word 2003 XML. This would make 14mb sample XML file :)
For XSLT lets take pipeline of three identity modes.
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:exsl="http://exslt.org/common">
<xsl:output method="xml" omit-xml-declaration="no" indent="no" encoding="UTF-8"/>
<xsl:include href="mode1.xsl"/>
<xsl:include href="mode2.xsl"/>
<xsl:include href="mode3.xsl"/>
<xsl:template match="/">
<xsl:variable name="mode1">
<xsl:apply-templates mode="mode1" select="node()"/>
</xsl:variable>
<xsl:variable name="mode2">
<xsl:apply-templates mode="mode2" select="exsl:node-set($mode1)/node()"/>
</xsl:variable>
<xsl:variable name="mode3">
<xsl:apply-templates mode="mode3" select="exsl:node-set($mode2)/node()"/>
</xsl:variable>
<xsl:copy-of select="exsl:node-set($mode3)/node()"/>
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template priority="-9" mode="mode1" match="@*|node()">
<xsl:copy>
<xsl:apply-templates mode="mode1" select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template priority="-9" mode="mode2" match="@*|node()">
<xsl:copy>
<xsl:apply-templates mode="mode2" select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template priority="-9" mode="mode3" match="@*|node()">
<xsl:copy>
<xsl:apply-templates mode="mode3" select="@*|node()"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
then write simple VBS/C#/Java code for benchmarking MSXML/XslCompiledTransform/Xalan
And results are:
Quite surprising winner, isn't it? In spite of Java slower to C/C++ and not compiled XSLTs...
| Attachment | Size |
|---|---|
| xml-pipeline11.zip | 1.92 MB |
| xml-pipeline11-2.zip | 8.89 KB |
Comments
what if there are a lot of templates with similar match="xxxx"
feed the XSLT with multiple nodes and choose template by attribute value and add a lot of templates to the XSLT.
Like:
<xsl:template match=step[@action='1']>
........
Try about 100 such templates
br
yuriy
done -- see attached
done -- see attached xml-pipeline11-2.zip
Source XML was changed from War and Peace to 30mb file which was generated using XMLgen from http://www.xml-benchmark.org/; around 50 <xsl:template match="item[@id='item49']" mode="mode1"> templates are in place.
MSXML time has not changed much, however Saxon time grew from 5s to 10s
ok, I got it messed up, time
ok, I got it messed up, time intervals are not related, since transformations are different. But the general message is: Saxon was 2x winner on first variant, now it is equal to MSXML.
actually MSXML timings were
actually MSXML timings were not including time to read the file and serialize the result -- other tests were including. Updated MSXML timings are 14s.
Saxon is still the winner for xml-benchmark.org files:
for 15mb xml-benchmark.org file -- Saxon 5s vs. MSXML 4s
for 30mb xml-benchmark.org file -- Saxon 10s vs. MSXML 14s
for 45mb xml-benchmark.org file -- Saxon 14s vs. MSXML 26s
Interesting, but your
Interesting, but your benchmark would need to be more detailed.
I have always seen Saxon as much better than the Apache stuff,
but I didn't suspect the difference was so big.
Java slower than C/C++ ? that needs to be assessed again as of now,
because Java 6 is dead fast and I know a few simple examples where
it beats a C++ compiler hands on.
If one handles bits and bytes maybe, but on this kind of processing
I see no reason why Java would be slower than C++.
Yes, Java is slower than
Yes, Java is slower than C/C++ just because every single method in Java is virtual. Unless your code is overflown w/ tons of final clauses, JIT does not have enough information to simplify calls.
I do not believe in extra magical tricks of JIT, just because simple fragment like:
String s1 = "...";
String s2 = "...";
String s3 = s1 + s2;
compiles to StringBuilder.
Of course, there are some special cases, like famous trick w/ for cycle on integers executing faster in Java, but that's not for real.
I think you cannot just claim
I think you cannot just claim "Java is slower than C/C++", it is in fact a complex question.
See for example the WP page on this topic: http://en.wikipedia.org/wiki/Java_performance
- "every single method in Java is virtual": 1) not sure. We don't know exactly what a JIT compiler does. 2) It is not that important on a modern processor. The vtable is very likely to be in the cache, so it is a matter of 1 or 2 machine cycles, furthermore all that is pipelined like hell.
- your example on string catenation is not very relevant. How fast is Unicode string concatenation in C++? ... depends on the library you are using.
- memory management is now 3X faster or more in Java, due to excellent GC, while malloc/free has probably not evolved for years
- in contrast with what you say, a JIT has more information than a C++ compiler. The Java semantics are cleaner than C++ and allow deeper analysis.
I am not claiming that "Java is faster". I just say it is not that simple.
The point w/ StringBuilder
The point w/ StringBuilder example is that it could be compiled to "String s3=s1.concat(s2);" and if Sun is not able to make such a trivial optimization, it is highly unlikely they have implemented JIT-optimizations such as "inline non-overridden methods, if new JAR gets loaded-in, uninline newly overridden methods"
http://en.wikipedia.org/wiki/Java_performance by itself says that Java performance it 1-4 times slower compared to C/C++, but what is missing, that it is a lot faster to code in Java: the time C/C++ developers spend micromanaging pointers/etc, Java developers spend optimizing algorithms. That's why Saxon wins -- not because of Java memory management, but because algorithms behind it are far more superior compared to MSXML, XslCompiledTransform or Xalan/XSLTC.
Competing XSLT processor authors should spend more time optimizing the algorithm, not doing tricks.
Disagree
Modern C++ programmers no longer spend their time micromanaging pointers. Templates have eliminated most of that for folks who are serious about coding in C++. What the are wasting their time on however is reinventing the wheel and re-reinventing the wheel.
The question is not C++ versus Java. It's..
MSXML being based on COM ends up running a lot more code than you might think. I presume you did not use the thread safe objects.
Way to go Saxon!
New Contestants
2x slower compared to Saxon
just fails w/ Access Violation error
Post new comment