Scott & all,
> > I don't think this is something that could be comprimised, but I do
> > think we could still be obtain the same if we added an extra mapping
> > between your DTM type triplet and the current XSLTC DOM linear types.
>
> I hate to do an extra mapping... there shouldn't be any need. Maybe there
> is a way to still get the linear sequence and yet not do the string
> concatination and substring business.
There is not need to handle any strings at all. As long as we can give
each URI/local-name pair that exists in the DOM an unique identifier
(regardless of prefix), and as long as these identifiers are in sequence,
there is no need for any string concatenations or other string operations.
> > There is not reason to use a Visitor on the AST for the stuff that
> > is currently done for XSLTC. Each node in the XSLTC AST fits easily
> > into a general object structure
>
> I don't think it's a question of fitting in well. A visitor pattern should
> work for these just as well. But, either way is probably OK. The build
> and rewrite of the AST is simpler if we use visitor patterns, I think.
What parts do we need to rewrite? I am probably very optimistic, but I was
hoping to just split the current functionality in two. The ast.SyntaxTreeNode
classes could contain the current AST node navigation stuff plus the
parserContents() method and added code for optimisations. The XSLTC's AST
nodes also need the typeCheck() (you may have to do that too) and translate()
methods.
I have little experience with visitor classes, but from what I understand you
would benefit from using them when the nodes in your AST differ in functionality
(the visitor becomes a container for methods that do not fit in the AST
object hierarchy). The tasks that are done in XSLTC's current AST nodes are
very, very similar - even the ForEach class and the ApplyTemplates class are
similar; they simply output bytecodes.
> > but the build-time
> > seems to grow exponentially with the size of the input. I am pretty sure
> > this is due to resizing of some integer arrays.
>
> We've run across the same issue. We will probably address this via some
> sort of chunked array scheme. But this has some cost for smaller docs.
Exactly. I've been playing around with the thought of using multi-
dimmentional arrays in place of one dommentional ones. Don't know if
we would benefit much from that, but it is absolutely worth a try.
Maybe we should evaluate the size of the input and chose one of the
two methods based on that?
> > But we could probably avoid a good few test-and-branch instructions...
>
> I agree that dead code is probably no big deal. But, there are a *lot*
> more structural optimizations to be performed than test-and-branch. I
> think I am saying that these optimizations should be performed on the AST,
> before you get to the details of the runtime. And then, of course, there
> will be more optimizations based on the runtime.
These are unknown waters for me, so please be patient with me....
Can you give me a few examples of such optimisations? I know that in
theory there should be room for many shortcuts, as XSLT is not a
programming language (nomatter what people say). The author of a stylesheet
should not have to be concerned with performance or even with the way in
which the stylesheet is processed. XSL describes the "what" and not the
"how", and all optimisation is left up to us...
Morten
