• ...@Gordon, I gues I got your (Espruino) 'byte' code... I like it a lot: a hybrid between jit and running 'on' the source...

    I always wondered how running 'solely and purely' on the source still can perform, because, for example, in an if-then at the end, the else - if present - including all its 'content' would have to be parsed, in order to find the end... that would perform 'poorly'... so much for '...purely'.

    Ever since you posted the pseudo code above, my back burner (mind) explored the potential VM construct you are using. Now, I guess, I know also why code uses up variables (variable space) - not just variables for variables and function entry points (which is just another type of variable) - but also unconditioned code segments: the code is parsed and 'code segment variables' are created (in a special variable space in a three structure), on which the VM then 'executes'. That's the way I would be able to handle quickly control structures. Separation of the souce into control structure and linear source fragments.

    Because you mention '...later version of Espruino', I wonder about proper coding for now: less nesting (of function declarations) and all in global (root) level of code gives you faster exection?

    For example:

    function f() { /* do something */ }
    setInterval(f,intervalTime);
    

    is more efficient than

    setInterval(function(){ /*do something*/ },intervalTime);
    

    This could/would(? - or at least partially) explain that the .bind() you implemented 'internally' is faster (AND variable space saving) than the 'self-built' construct with an anonymous function and - most of the time needed - _this or that variable holding on to the this (for proper resolution in the closure / deferred execution context, which has a different context / this...).

About

Avatar for allObjects @allObjects started