JIT vs Inline C/JS EspruinoCompiler?

I think there are a few big drawbacks with server-based stuff:

• It's heavily tied to the firmware version since it uses internal functions. Sometimes if you had uploaded apps they would just lock up the watch if you updated your firmware
  
• It needs an internet connection, which people always complain about
  
• It'll thrash my server :)
  
• Trying to keep server + firmware versions in sync is going to be a real pain
  
  

As you've noticed I've been trying multiple options, but so far none of them have been that great, and it's always felt like a bit of a hack. I've got a company using the Espruino firmware in some custom watches of theirs, and they're actually avoiding the JIT even though maybe they could do it because it's just an extra layer of difficulty. However the JIT compiler in the firmware seems promising to me... So far it only uses 4kB Flash and even now there's a 2x speed improvement.

Normally Espruino is pretty slow, but there's no one big time hog. I guess roughly (this is just a guess) time is spent:

• 30% Lexing the text itself
  
• 15% Parsing
  
• 40% Variable lookups
  
• 15% MathsOp (actual maths operations)
  
  

Even if we use GCC and some optimisation, we're still going to have the Variable Lookups and MathsOp in a lot of cases, so it may not actually be that fast.

By contrast, if we use JIT on the device, we can actually get the address of built-in functions and can call them direct, so in many cases we can skip the expensive variable lookups. The JS compiler on the server does this in one or two small cases where the JS function is be exposed (eg digitalWrite) but it doesn't do it for many at all.

The reality is that most of the code is just stringing together calls to built-in functions (jsvUnLock,jsvMathsOp,jspGetVariable...,­etc) so actually simple JIT on the device can do that pretty well. Obviously if we're at the point where we're really compiling the JS into C that's dealing with ints and doubles directly then GCC will be a lot faster, but I don't think in a lot of cases we're really going to be doing that.