-
Topic: Flat Strings
Big mis-understanding here.
I read (four months ago) 'New Espruino IDE Posted on Wed 14th, February 2018':
Which caused me to post back in Oct
From #2
'So in your case, your arraybuffer just isn't big enough that it makes sense to allocate it as a flat string. Make
it size 32 or something and it'll work.'and #3
'what I suggest (E.toString) is actually . . . so that would be a good starting point.'
and #2
'you'll find E.toString is much more reliable at creating flat strings.'
'I'd suggest the little known hack of E.toString({data : 0, count : NUM_BYTES})'
http://forum.espruino.com/conversations/316409/#comment14077573The third example in #1 at:
that and comments in other posts led me to believe that the technique shown was to use
E.toString()
when making the arrays because of the size required. [900 bytes] The goal was to have fast sequential and random array access to output withinsetInterval()
What is happening is that when arrays are small <8 elements, code execution (Javascript only) is acceptable. When creating larger arrays, >32 elements, code execution gets progressively and perceptibly slower (when using setInterval()) as array size increases. In order to access the largest 5 meter Neopixel strips will require array sizes of 900 elements. [60 neo/m * 5m * 3rgb] I have a design/speed reason(s) to stay away from
Uint24ClampedArray
Are you uploading the exact same code you did with the exact same firmware when it worked?
The compiler shouldn't be an issue - it was a config problem on the server but the compiler itself didn't change.
If you were to 'save on send' to 'direct to flash' that would give you a bunch more available memory. If you'd had that on before, and had changed it back, that would have broken things.
I should add that it's not just that saving to flash gives you more memory, but it also doesn't save the function declarations to the command history, which means there's far less fragmentation.
Espruino doesn't allocate variables on the stack - they're all in one chunk of statically allocated memory.
stackEndAddress
really isn't a useful number for you to look at.This scans the whole variable and everything it links (like if you ran
trace(var)
) - it's showing you the size of the object, all variables, all functions, and even any variables/functions in scopes that those functions were defined in.When you go down a level to output data, you might have two functions that are defined in the same scope. Both of those functions will bring in the same scope so will be more or less the same (huge) size.
Yes - because the act of sending (which is creating loads of functions and even executing them) can fragment memory.
It's most likely fragmentation - especially as you're using over 2/3 of your memory. The quick explanation is:
In both cases there's the same amount of free memory, and the same amount used.
This is one of the reasons I suggest that you just leave Espruino to do its own thing. If you created arrays the normal way:
Espruino would automatically allocate flat strings for all those arrays, except if it couldn't find a big enough block of memory - in which case it would just allocate a normal String and continue perfectly fine, just a little bit slower.
Of course if you are trying to write C code to access the raw data as a char array then you'll hit problems - but if you're using compiled JS or just normal JS you'll be fine.