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