Some pointers about the implementation of JS in Espruino is very welcome here. I provide an example from code I'm working on (Part of this conversation - including some helpful responses - began in http://forum.espruino.com/conversations/255757/ about GPS module and Extensions there of. It is now its own conversation for separation of concerns.)
I needed an array of strings - keys - for processing. So I created an array of strings in the source code and it got me quickly out of memory ( #outofmemory ) into the 'out of memory jail':
In a desperate move - with no real rational but just some guessing - I chose to group the keys w/ space as separator in fewer strings and apply some joining and splitting before processing to keep the same algorithm (because of performance) - and 'miraculously - it got me out of 'out of memory jail' (The joining-splitting with/by space is possible because the keys cannot include spaces):
You may have notice in the above code the line keys = keys.join(" ").split(" ");
Even though I then kept/stored the joined-splitted-processed array, I was kept out of 'out of memory jail'. It must have to do something with how source code of arrays of string literals is pulled in and hold onto.
What is the 'somewhat puzzling' key-note to take from this experience?
PS: I had temporarily similar experience as mentioned in 2nd reference above, even though I used the fixed version of the .indexOf(...) - [1v70]. The issue showed in the GPS modules handleGPSLine when going for the decimal points with indexOf('.') in the lines received from the GPS receiver. Could it be that the .indexOf() String method is still a bit 'weak on its legs'. Having read about it I felt it had something to do by releasing the search argument string... but I may be totally wrong about ti. As said: it was temporary. Nevertheless, observing it cannot hurt.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Some pointers about the implementation of JS in Espruino is very welcome here. I provide an example from code I'm working on (Part of this conversation - including some helpful responses - began in http://forum.espruino.com/conversations/255757/ about GPS module and Extensions there of. It is now its own conversation for separation of concerns.)
I needed an array of strings - keys - for processing. So I created an array of strings in the source code and it got me quickly out of memory ( #outofmemory ) into the 'out of memory jail':
In a desperate move - with no real rational but just some guessing - I chose to group the keys w/ space as separator in fewer strings and apply some joining and splitting before processing to keep the same algorithm (because of performance) - and 'miraculously - it got me out of 'out of memory jail' (The joining-splitting with/by space is possible because the keys cannot include spaces):
There are several conversations out there about memory and out of memory and I reference them in this list:
GPS code/module/library leaking memory before 'satellite lock' occurs
Out of memory?
But none of them can explain the following:
You may have notice in the above code the line
keys = keys.join(" ").split(" ");
Even though I then kept/stored the joined-splitted-processed array, I was kept out of 'out of memory jail'. It must have to do something with how source code of arrays of string literals is pulled in and hold onto.
What is the 'somewhat puzzling' key-note to take from this experience?
PS: I had temporarily similar experience as mentioned in 2nd reference above, even though I used the fixed version of the .indexOf(...) - [1v70]. The issue showed in the GPS modules handleGPSLine when going for the decimal points with indexOf('.') in the lines received from the GPS receiver. Could it be that the .indexOf() String method is still a bit 'weak on its legs'. Having read about it I felt it had something to do by releasing the search argument string... but I may be totally wrong about ti. As said: it was temporary. Nevertheless, observing it cannot hurt.