It is inevitable that XSLT will be applied to transform XML in many scenarios. Recent posters to the XSL-List have been looking for fast ways to transform large quantities of XML, and have been finding current XSL processors somewhat wanting.

Clark Evans posted a detailed investigation in his problem domain, financial information, and suggested some alterations for greater processing speed.

However, these suggestions have met a mixed response. In particular, it seems that Evans' optimizations run against the "functional-programming spirit" of XSLT. Oren Ben-Kiki suggests that in fact removing the restriction on matching on result tree fragments (output generated by a previous application of an XSLT rule) would solve Evans' problems.

Chris Maden comments "don't try to sharpen my hammer because you want to drill holes with it", inferring that other tools might be better for this problem domain.

One thing is certain: this isn't a problem that will go away quickly. The functional-programming culture of XSLT conflicts with the largely procedural, side-effect hungry, mindset of most programmers: making it harder for them to write efficient XSLT stylesheets.