Subject: RE: XSL Compilation From: Joerg Pietschmann <joerg.pietschmann@xxxxxx> Date: Fri, 24 Nov 2000 18:42:29 +0100 |
Mike Kay wrote > No, I abandoned work on the Saxon XSLT compiler, when I found that the code > was running slower than the interpreter, and that the unimplemented features > (including namespaces) were going to be very difficult to do. > > The only XSLT compiler project I'm aware of is the one at Sun. > > Personally I'm now sceptical whether it's the right way forward. How many > successful SQL compilers are there? It depends. All DB manufacturers i know of have a precompiler which produces preparsed internal representation of SQL statements for faster network transfer (using handles) and avoiding reparsing repeated statements. This is probably equivalent to Xalans's compiled stylesheets. Some DBs do also major optimisations in this process, sometimes resulting in quite significant speedups (i've seen a factor 5 personally). I'm not sure what time consuming optimisations could be applied to XSL, but i'm sure there are some. Using term rewriting for XPath predicates might be an application, possibly resulting in common subexpression elimination in successive XPath statements. The "fast numbering across gaps" problem may also be solved this way. Another possibility might be the evaluation of the DTD of the XML to be transformed, for example if the DTD says <!ELEMENT foo (a,b,c)> and i have an XPath "foo/x" in my XSL, it could optimise it away and possibly emit a warning message too. J.Pietschmann XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSL Compilation, Kay Michael | Thread | Performance versus legibility, Richard Birkby |
Re: doctype, Dimitre Novatchev | Date | RE: doctype, John Power |
Month |