Now testing: Somewhat faster version of Counterfeit Monkey

Quixe already uses a JIT. There’s lot of scope for improvement, but it will also take lots of work.

I’ve thought about turning Git into a node module, but I’m not sure how difficult it would be to make it work well.

I looked at the “JIT”, it just just does naive translation doesn’t it? The problem of making a proper JIT or even AOT compiler (because do you really need to support self modifying Inform bytecode?) just seems inefficient if you can work on the i6 code directly - if you could translate an i6 functions directly into a JS functions you don’t need to emulate a call stack, program counter, etc but also because then the browser can do more optimisation on the resulting JavaScript.

Eh, maybe, but I don’t think it would help. Firstly in order to keep savefiles transferable, to use the same UI systems, etc, we really need all of that. And the cost of those is not high, and by leveraging the JS VM’s own JITs they perform really well already. There are two things that would further improve the performance of the JS terps:

  1. Porting the emscripten relooper
  2. Tracking which functions can safely be called directly and which we don’t need to worry about halting and saving the state within them (which would in effect turn all of those functions into accelerated functions)