> 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 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.
> 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.
> 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.
-scott
