You are reading a single comment by @allObjects and its replies. Click here to read the full conversation.
  • @Gordon, thanks for your detailed response. I eliminated some functions and added some ifs - to de-modularize increasing dependency and tighter coupling - to get temporarily over the issue - not the preferred SW best practice. Since it is in (the infrastructure) framework, it is manageable.

    When increasing application complexity without going more asynchronous, I expect it to happen again.

    Is there a way to ask the Interpreter how much stack space is left and a rough/average break down into number of nested function calls?

    Another question is how do fat arrow functions compare to standard functions? I know about some limitation but that may be different in the Espruino context with interpretation on the source / no byte/intermediate code.

    Regarding minification, which is not directly stack / nested calling related but share the memory restrictions: does the Esprima minification take this into consideration? Using google's closure compiler service for JavaScript has often a negative effect: this and undefined and some other constructs that are great w/ byte code but not with source interpretation, and the compiler is so smart that it requires some tricking to keep it from resolving and substituting. I'm aware of the some of the penalty by using a variable vs a constant, but memory is absolute, (execution) time can be stretched.


Avatar for allObjects @allObjects started