[pizlonator]

Not tracing. Speculation.

The difference is that you compile user control flow as-is unless you have overwhelming evidence that you should do otherwise.

And yes you are right. This is promising for run-once code, but all of the cost will be in dynamic things like the envGet. An interpreter can actually do better here because most environment resolution can be done as part of bytecode generation. So it’s possible that this experiment leads to something that is slower than JSC’s interpreter.

[ridiculous_fish]

Agreed that envGet() will be brutal, but optimizations can eliminate a lot of that, e.g. by promoting locals to stack variables instead of heap variables.

It is possible to statically decide which environment contains each upvar. So I don't understand your conclusion that this experiment may be slower than JSC's bytecode interpreter. What information can JSC exploit at this stage that is statically unavailable?

[arcticbull]

Yeah, and escape analysis could be used to avoid putting variables that can't be easily placed onto the stack in the scope of a garbage collector. Further optimization work could be performed to compute variables with constant results or to partially compute expressions. It's interesting, got me thinking about building one.

[arcticbull]

I got to thinking... with the right types, isn't it possible to take each JS function and emit a Rust generic function over every JS type (value/object) and have the Rust compiler emit optimized code for each specialization. Each invocation at compile time can be optimized by the Rust compiler then and so long as there's no eval or dynamic dispatch in the translation unit, each call should be maximally efficient and all unused paths can be trimmed statically.

[pizlonator]

Not possible to do statically if you’ve got eval or with. But maybe this experiment will not support those.

JSC has speculations that eval won’t introduce variable names we’ve already resolved for example.