KJS "compilation" phases

[Harri Porten]

Hi all,

After the battery of my laptop died on a long train ride I had some
time to think about the future KJS design. I'll skip ideas that affect
the external interface (e.g. a C++ wrapper API for extension writers)
and concentrate on the internal parsing & execution aspect.

Benchmarks run after recent improvements applied by Maksim and
Christoper show a drastically improved performance compared to KDE
3.x. Still, there are several low-hanging fruits for improvements
left. And equally many higher hanging ones.

I do not want to discuss any details right now but focus on the main
phases of parsing and execution right now. What we have now is
(roughly speaking)

a) Tokenizing
b) Parsing
c) Node creation (including small optimizations)
d) Declaration processing (on the nodes)
e) Execution (on the nodes)

Lots of improvements local to each phase our on mine and other's todo
list. But these can be eased and furthered by a reworked overall
design. I'd like to introduce a "fast path" for some common JS
operators for example. This can be accomplished during the parsing
stage by creating some specialized nodes in c). I implemented this a
while ago and saw a very good speed improvement. On the downside this
leads to an explosion of the number of Node classes. Maybe this cannot
be avoided. The Node tree even improved useful for Maks' work in phase
d). But I'm not sure whether we want to pass this complexity on to the
execution phase. Instead, I am wondering whether we should introduce
another phase before e) or combine it with d) and produce a different
output for execution.

However this final "code" would look like I am wondering whether the
extra cost of producing it can be justified in all cases. After all,
KJS main use is for Web pages and we do not want cause a negative
impact on page loading for a script that is only executed once. Hmmm
... JIT compilation.

Any thoughts? I'd like to develop a vision before we apply local
optimizations that will make bigger changes more difficult lateron.

Harri.