Sami Vaarala

I'd also be happy to help in whatever way I can. I'm working with Duktape's native CBOR binding so I could help at least with bug fixing and maybe improve...

There's currently no support for compiling JS code to native code right now. I wouldn't exclude it from future work, but it'd need to be added in a modular manner...

Probably not in the near future, unfortunately. There's more important work (ES6 stuff for instance) and no volunteer with JIT experience to spend a lot of time figuring out a...

A little clarification to the above: I don't mean all those optimizations would need to be implemented right away. But there needs to be an architecture which allows them to...

Hmm, I don't see how a tracing JIT would handle e.g. property access optimization any better than a per-function JIT, considering that properties can change arbitrarily at any time? The...

If one were to implement JIT right now it'd be easiest to base on converting bytecode into machine code. An AST would of course be preferable and that will become...

@indutny Here's an example of how the current code generation works: https://github.com/svaarala/duktape/blob/master/doc/compiler.rst#ivalue-example In short, there's a tiny fragment of an intermediate representation, one step away from becoming a RHS or...

From code structure point of view multiple targets would need to be supported (at a future time, of course). There are targets running x64, x86, ARM, PowerPC, SuperH, MIPS, Motorola...

Direct threading might enable incremental optimization because one could replace opcode sequences with target functions implementing the sequence in an optimized manner (even up to full traces maybe). But it's...

Regarding property accesses, there's obvious room to improve the hash and lookup behavior (planned for 1.5.0 release), so some improvement in coming in the near term. One relatively simple approach...