You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • Yes, memory units of 20 bytes is right. Just for anyone else:

    1988 (after reset) - 1841 = 147
    147 * 20 = 2940 bytes
    

    Note: I've discovered a bug here, which is that process.memory().history (which is the amount of memory used for the command history) is being calculated wrong, and so that knocks all the calculation of 'free' memory out. My info below is with a development version that now has this fixed. When 1v48 comes out that should have the fix in.

    What I think is happening is that the script is being executed, and is generating variables/functions which are using up more space than just the individual characters. If you just had one function that wasn't executed then the situation would be a lot better.

    For instance:

    >process.memory() 
    ={"free":1988,"usage":12, ...
    
    function foo() {
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX­X
    XXXXXXXX
    }
    
    >process.memory()
    ={"free":1953,"usage":47, ...
    

    So the code above (which, incidentally is 490 characters) uses 35 blocks in total which is 700 bytes.

    Of that:

    blocks use
    1 The function name foo
    1 A Block saying 'I'm a function'
    1 A Block saying 'I'm a function's code'
    31 String data, as Espruino uses 4 bytes out of each 20 byte block for other stuff (490*/16=31)
    1 When we typed process.memory() to query the memory, it added one block named process because we referenced it and it wasn't there before. This is something that could be fixed later though

    You can type trace() (a debug tool for developers) which outputs the raw structure of the interpreter's data, and that might help to explain where your memory is going...

About

Avatar for Gordon @Gordon started