Subject: Re: [xsl] how to estimate speed of a transformation|
From: "J.Pietschmann" <j3322ptm@xxxxxxxx>
Date: Thu, 11 Dec 2003 15:23:49 +0100
I am not asking for anything which is not here.
These technologies have been developed partially in parallel with the spec but mostly afterwards. We will probably see more improvements in the future.
The real question is: why should a language spec require a specific processing model for a bunch of specific optimizations? It may turn out this prevents some much more important optimizations later, which wasn't obvious while the spec was created.
Wandering somewhat OT for this list: for the classic languages and compilers, competition and market pressure market worked. If you wanted to sell a compiler, or some hardware with a specific compiler, you'd make damn sure that - it will provide a benefit for the target group - the competition would have a hard time to provide the same benefit. Note that it's basically impossible to sell a C++ compiler nowadays which doesn't implement for example constant folding or clever automatic inlining, although the C++ spec doesn't mandate either of these.
OTOH, for any specific project/product there will always be limited development capacity to implement every conceivable optimization at once, so they have to pick some which they deem to the most profitable (whether the profit is money or ego-boost or whatever).
Why don't you pay bick bucks to, say, the jd.xslt developers and tell them to implement exactly the optimizations which make running your style sheets ultra-fast?