More speed and code size improvements

The latest builds of Espruino have some big code size and speed improvements...

• Functions don't store { and } - this can mess up your code formatting a little if you call dump() and you don't use the 2 character indents that are generally used in Espruino code, but it's worth it - a lot of RAM gets saved
  
• Simple Functions of the form function (...) { return ... } don't have return stored internally. This saves a bunch of space and improves execution speed.
  
• Small strings (<=10 chars on Espruino boards) can now be fitted into one variable. Anything over 4 got put into 2 variables before.
  
  

So... execution speed has increased:

function sum(a,b) { return a+b; }

function test() {
  var arr = new Uint8Array(10000);
  var t = getTime();
  var res = arr.reduce(sum);
  console.log(getTime()-t);
}

// 1v81
>test()
1.40450859069

// current build
>test()
1.18919467926

And, memory usage has reduced a lot, at least in some cases:

var a = {
  a : function() { return alice; },
  b : function() { return bob; },
  c : function() { return carrie; },
  d : function() { return dave; },
  e : function() { return elise; },
};

// 1v81
>E.getSizeOf(a)
=29

// current build
>E.getSizeOf(a)
=21

It should really shine when using minified code (for instance all of Espruino's modules).

But these are some big changes - while I do test here, it'd be great if some of you could give the latest images a try and see if you encounter any problems.

As usual, you just go here and find a build for your board (Pico or Original Espruino boards only, and you probably want the WIZnet one). Then, right-click and copy the URL of the .bin file, open up the Web IDE, go to flashing, and paste it into the URL under Advanced Firmware Update and click the button next door to it.

Just to add a real world example:

var w = require("ESP8266WiFi_0v25");
console.log(process.memory().usage);

// 1v81
618
// current build
520


var w = require("MQTT");
console.log(process.memory().usage);

// 1v81
467
// current build
403

...impressesive... the 'lemon' is not empty/dry yet... lemon in a good sense of the word...

Just recentl when you fave feedback of a fix, I was wondering where do you still find the space - in the EEPROM - to get all the fixing and enhancing changes to be swallowed. Of course in this and related posts, you are talking about RAM. I know that code that gets better gets leaner... but only up to a certain point...

Well, the Pico has bags of Flash, so we're nowhere near having any problems with that. On the original board it's getting more tight, but I have spent a lot of time recently trying to lower the Flash usage - to the point where I even have a tool that scans over the code finding sequences of assembly instructions that are repeated and which could be merged into a single function!

Generally a lot of the tweaks and fixes don't use a lot of memory though, it's just when there's completely new functionality.

It is getting extremely tight on boards with 128kB like the Olimexino, and I do often end up cutting features out for that when I don't think they'll be used.

Doing this:

function test(){return;}

now results in:

Uncaught SyntaxError: Got ';' expected EOF
at line 1 col 1

That used to work. While this case is trivial, it may point to a deeper problem with this change. How is it getting to a point where it's complaining about the semicolon? function test() {;} goes through without a problem.

That aside (and in my case, there was no good reason to have the return at all, so it doesn't cause any problem for me), this is a very exciting change!

Thanks! Luckily it's a small problem - it's literally just that in this case it assumed there would always be an expression after the return if it was the first statement in the function. I'll try and get a fix in for that now.

If you instead did function test(){1;return;} then that should work fine.

...a parser/lexer down to the atoms!