>> 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:

Indexdata++

MJ