>> The first comment claims a 30-40% increase in XML parsing, which seems obvious when you compare the number of characters in the example provided: 277 vs. 419, or about 34% fewer going through the parser.
> The speedup can be much greater than that -- from the blog post
> itself, "Using xsltproc --timing showed that our transformations were
> faster by a factor of 4-5. Shortening the element names only improved
> performance fractionally, but since everything counts, we decided to
> do this as well". xsltproc uses the highly optimised LibXML/LibXSLT
> stack, which I guess maybe doesn't have so much constant-time overhead
> as the PHP simplexml parser that yielder the smaller speedup.
Sure, but XML parsing (libxml) and XSLT (libxslt) transforming are very different operations. I would expect parsing to scale linearly with the byte-length of XML being parsed. XSLT, on the other hand, is presumably much more dependent on the complexity of the XSL being applied (depth/structure of XML, number of templates matches, complexity of XPath statements, etc.)
So I'd expect a series of XSLT transforms to have a much more variable change in performance than just parsing. As I say, if you're writing custom XSL anyway, then certainly having a more compact syntax is going to yield better performance.
I'm sure to those for whom Turbomarc is useful, it's *very* useful, but it definitely seems to be nearing the limit of the readability-performance balance. ;-)
Also, standing w00t: