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.