Saxon

Legacy ID: #8839785 Legacy Poster: Michael Kay (mhkay)

I don't see any surprises here. As far as I can see your two benchmarks are measuring very different workloads, so it's not clear why you would expect to get the same result. Different processors are going to perform better or worse depending on what you throw at them. For example some processors might spend a bit longer building the tree in order to make it faster to navigate, and that decision will benefit some workloads and not others. It would be interesting to see more detailed analysis here, for example to compare the time taken to build the tree, the time taken to do the transformation, and the time taken to serialize the result. You've making some very wild conjectures about the factors that influence performance, for example that you would expect C++ to be faster than Java. Well, an XSLT processor has to do dynamic memory allocation. If you write it in Java, you get the benefit of Java's memory allocation, while in C++ you have to do it yourself. So the question is, if you're writing an XSLT processor in C++, can you do memory allocation more efficiently than Java does it? And in my experience, the answer is usually no. You might like to read http://sites.computer.org/debull/A08dec/saxonica.pdf for my analysis of the factors affecting Saxon performance. It's written from an XQuery perspective, but most of it applies also to XSLT.

Legacy ID: #8841767 Legacy Poster: Andriy Gerasika (andriy_gerasika)

Well, fixing the timings for MSXML shows that it takes 2s to construct the DOM for 30mb document, 2s to serialize, and 10s to process. Apparently constructing the DOM is not so heavy operation, as I thought. 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 I do agree that benchmarking differs from file to file, but how to benchmark and prove Saxon is generally faster compared to MSXML/XslCompiledTransform/XSLTC despite of various C++/compiled XSLT tricks? p.s. The paper says it is more optimal to write empty(...) instead of count(...)=0. Does the same apply for not(...)? I very often write <xsl:template match="a[not(node())]"/> should I be using empty() instead?

Legacy ID: #8841985 Legacy Poster: Michael Kay (mhkay)

The paper says it is more optimal to write empty(...) instead of count(...)=0. Does the same apply for not(...)? I very often write <xsl:template match="a[not(node())]"/> should I be using empty() instead? Saxon usually sorts this kind of thing out for you. If the argument to not() is statically recognizable as a node-set, Saxon will rewrite not(X) as empty(X) automatically.

Legacy ID: #8929429 Legacy Poster: Andriy Gerasika (andriy_gerasika)

closed. The company I work for, will be upgrading from Xalan/XSLTC to Saxon.