KJS "compilation" phases

[Luciano Montanaro]

On giovedì 17 maggio 2007, Harri Porten wrote:
> 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 have noticed. Nice work!

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

An optimize phase? I have been thinking about that, too. I'm not familiar 
enough with the KJS internals, but I think it could be useful.

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

I think an optimization phase could be very useful. For sites using "light" 
one-run-only JavaScript it may slow down loading a bit. As long as it is 
not noticeable, that should not matter. But there are many sites that use 
complex scripts, where compilation (or simply optimization) could really 
make a difference. And the trend seem to be for more dynamic sites...

Luciano



-- 
./.. ../ /./. .. ./ /. ///   // /// /. / ./ /. ./ ./. /// ././. //
                                                            \\ //
                                             www.cirulla.net \x/