What's included in memory.js?

[Guy_]

Whilst trying to slim memory usage it would be useful to know what's included in the memory count.

Are resource files included, if not yet referenced or opened?

is the Index.gui counted in the memory?

Is it better assign text to a field in the SVG or have an empty SVG field and assing it in the app?

Is there a limit to the number of functions?

Are functions with parameters more memory hungry than using a global variable?

Any other tips for saving memory?

Is there a difference in how memory is assigned and calculated between OS 4 and OS 5?

[Gondwana]

I assume you're talking about RAM usage (eg, the 128kB), rather than package size.

Resource files themselves aren't counted.

I think that .gui (SVG) files are counted. For example, if you put 300 elements in a .gui, your memory usage is high. However, I suspect that the SVG is parsed on installation and it's the parsed structure that takes the memory; not the source code in the .gui file itself. You might be able to check this by inspecting the runtime snapshots produced inside the sim.

I'm GUESSING that assigning text inside SVG will be more memory-efficient than doing so in JS. Reason: being a largely static structure, the SVG can be parsed and stored in memory at installation time (or maybe even at snapshot creation time), whereas your JS code will need to include the extra JS instructions needed to do the assignment.

A possible exception to the above would be the use of i18n files. I believe that strings stored in i18n files aren't all counted against your 128kB. Strings loaded from there into memory are presumably counted, but if you don't need all of them all the time...

I don't think there's a limit to the number of functions per se, but functions do consume memory, of course.

If you're using functions with parameters, you're probably using less global variables. That's beneficial because the memory for local variables can be reclaimed by the garbage collector and used for other things when necessary.

Here are some semi-random references:

• https://github.com/Fitbit/developer-bridge/tree/master/packages/memory-profiler
• https://github.com/gaperton/ionic-views/blob/master/docs/optimization-guidelines.md
• https://gondwanasoftware.net.au/index.php/fitbit/sdk-faq/crashes-reliability-and-performance#3596
• https://en.wikipedia.org/wiki/Immediately_invoked_function_expression

[Guy_ · Accepted solution]

Thanks Peter, more or less as expected.

However a JS that works on a Sense runs out of memory on a Versa which would indicate a difference between watches or OS levels, strangely it seems to not run out of memory on a Versa 2.

What is the different Ram memory limit per OS or per watch?

Unfortunately the "out of memory" isn't picked up with the OS Simulator, it probably would be good to have a memory limit detector built in to the Simulator, so one could detect how much a JS uses and where it falls over too, and use it to trim the execution and produce better apps.

One optimising trick I developed which helped, and may not be commonly known, was

To dynamically define elements in function called from a loop. eg for 24 elements h00-h023

const H = document.getElementById("h"+util.zeroPad(index));

That way only a maximum of one element exists at a time [instead of 24 predefined], and 0 when the routine is finished, whilst at the same time simplifying processing down to only one element instruction, instead of 24 separate instructions.

[Gondwana]

RAM for Versa (1), Lite and Ionic is 64kB. RAM for Versa 2 (with current firmware), 3 and Sense is 128kB.

Unfortunately, the simulator can't simulate memory usage well because it's a 64-bit app whereas the watches are 32-bit. This means that apps take more memory in the sim; to avoid spurious out-of-memory errors in the sim, it gets twice the memory that the physical devices get.

I like your getElementById trick. getElementsByClassName (etc) can also be used to process groups of elements, but that won't have the potential memory saving of your approach. That said, using local variables, or nulling variables once used, does allow their memory to be recycled.

I suspect that element objects (such as those obtained using getElementById) are not created when getElementById is called, but perhaps when the SVG document is loaded. My tenuous evidence is this: if you make a change to such an object (eg, by adding a property), free it, then get it again later, the change you made is still there. If so, such objects persist throughout the lifetime of the app, or at least the current document. Ergo, the savings made by not keeping references to them may not be as great as we'd first think. ☹️