@Robin, in an object-oriented / memory managed / garbage collection enabled system calculations aren't that straight forward... also while an expression is executed, reference (vs. old way allocated) amount of memory can be a multiple of what the statically calculated demand is implying. Depending on the object granularity, the meta data / organizing data may outweigh even all the time the amount of actual user / payload data. A VM interpreting on source is even more susceptive to these challenges than a VM executing byte code. Byte code - like compiled code - is much more machine oriented than the high-level programming languages that we use these days. At one time, COBOL was thought to be high-level, compared to today's oo JS, it is gold-plated assembler at best.
Reading beyond the code lines you publish, I assume you want to keep multiple frames of neopixel display (string) data. If it is all dynamic and constantly changing, you have to have it in some fast/easy to access memory. Did you ever think to put it into some serial RAM / FRAM / MRAM?
The question is also what you use to manipulate these frames/buffers... If you want to manipulate them with the Espruino Graphics object, it has to be the Espruino's 'internal' memory... otherwise, it can easily be 'external'... as mentioned before: serial xRAM. Flash may work too, but may be cause challenges because of the write times and wear.
It all depends... is always the right / correct answer... but only helpful to get the questioning / thought / design process going.
Observation: Memory not freeing up after call to E.getSizeOf() anomaly
I performed the following with over 1500 blocks of free memory.
E.getSizeOf( memFree, 2 );
New interpreter error: MEMORY
Which resulted in the MEMORY error and the consequence of having only 600 blocks remaining. Memory doesn't free up under this condition. E.getSizeOf() seems to leave it's contents in memory which if not paying attention could cause the same issue I was having. (this wasn't the case and only observed once) I only caught this as I was deep in attempting to understand what was going on. Others might not be as observant.
Thank you @allObjects for reminding me of the available Graphics object. I did revisit the online docs, but found it more suitable for fonts, polygons and X-Y position manipulation. My need is more random array offset intensive and requires a slightly different technique.
It has been quite the challenge to put ten pounds of sh*t into a five pound can as I am attempting to maximize the array sizes to handle the five meter strings while still allowing for code space for the end user play area. A constant trade off of removing desired code for that which is absolutely needed. Still may have to abandon this project as the desire is to not have the user acquire additional memory hardware.
© Espruino, powered by microcosm.
Report a problem