Preserving memory in Monkey C

As for couple of last days I was fighting hard to preserve every single byte of memory, balancing just at the edge... maybe others will find that usefull - and even more - maybe Garmin will work on that to improve as well?

1. Do not use SWITCH / CASE construction. Instead - use IF / ELSE IF construction. It preserves memory, maybe not a lot, but always few bytes or more.

2. This is ridiculous? Do not use CONST variables. It looks like using directly values preserves memory. Don?t like it, but no choice there

3. It is beneficial to create a function whenever 2 or 3 lines of code are repeated. Just use params if required. It will save space

4. Avoid use of dictionaries!

5. For memory consuming operation try to assign to every non used variable NULL ? this will free memory

I'd appreciate - as the whole community - if others would share their findings too!

Top Replies

All Replies

FlowState 8 days ago in reply to SimonJEdwards

SimonJEdwards said:
Can you give me an example of the settings names you changed, for example did you change the Properties names, String names and the Settings names?

They meant the property IDs, which are strings. (Each setting is associated with a property.)

String IDs are symbols (integers), the literal names only exist in source code and debug info (same goes for other resource IDs). Settings don't have their own IDs per se, as each setting is tied to a property.

e.g. Before:

After:

peterdedecker 8 days ago in reply to FlowState

unless you're developing for old devices then memory should not be much of an issue nowadays really...

in the early days it was a real art to get everything in your app (I refactored the code a lot), but today I think the limits are generous. And with the graphics pool in play there's almost no worry about the graphics resource part (currently that is - I'd actually love to see Garmin impose a limit on the developer how much of the memory an app can use from the graphic pool as this is not an ENDLESS resource)

FlowState 8 days ago in reply to peterdedecker

peterdedecker said:
unless you're developing for old devices then memory should not be much of an issue nowadays really...

Yeah I agree in general, I was just answering the question. Obviously with the advent of the Monkey C optimizer and the increased memory limits on most combos of app types and devices, most of this advice is obsolete.

peterdedecker said:
it was a real art to get everything in your app (I refactored the code a lot)

Yeah this is one of the reasons I won't share any of my old app code on github. Everything I had to do to save memory is the exact opposite of what would normally be thought as best practices for code that's easy to understand and maintain.

peterdedecker said:
unless you're developing for old devices

However, ppl have been saying this for years, and it seems there's always an exception or two to the rule, where a current device still has a limit of 32 KB for data fields, unlike most of its peers. Obviously not as bad as the 16 KB limit for super old devices, but it's still fairly tight.

e.g

- in the past: Vivoactive 4

- now: Instinct 3 Solar, Instinct E

I have an (old) data field with basically 3 tiers of features, depending on memory limit: 16 KB, 32 KB, and over 32 KB. (It came out at a time when the 32 KB devices were most common. Obviously today I could simply choose not to support any devices with 32 KB or less.)

flocsy🤠 7 days ago in reply to FlowState

I gave my old watch (fr245) to my son, bought a used fr55 to the other son, so we still have 32kB devices.

I'll add one more fact: I tend to support all (sometimes except epix) devices. One if my apps is most used on fr55. Ok, it's not as old as 245, but still. Actually I sometimes search for apps for them and I can't find the apps I use on my 965. Contacting developers usually doesn't help. Creating a similar app for old devices can get a nice amount of downloads.

SimonJEdwards 7 days ago in reply to FlowState

What do you mean by "Monkey C Optimiser"?

FlowState 7 days ago in reply to SimonJEdwards

FlowState said:
Obviously with the advent of the Monkey C optimizer and the increased memory limits on most combos of app types and devices, most of this advice is obsolete.

SimonJEdwards said:
What do you mean by "Monkey C Optimiser"?

I mean the built in optimizer in the Monkey C compiler - sorry I wasn't clear about that.

https://developer.garmin.com/connect-iq/monkey-c/compiler-options/

As an example of what I mean by advice in this thread which is now obsolete: in the past it was recommended to not use constant variables or enums in source code, but instead to hardcode the corresponding values as numerical literals, in order to save memory. Obviously this is bad advice from a style / readability / maintainability perspective - it's only good for saving memory. Nonetheless, a lot of us did it because memory was tight. I would replace enums with their values, but also put the original enum in a comment next to the value. Still not a great practice.

This advice is obsolete because the optimizer will replace enums with their values at compile time. But at the time the advice was given, the optimizer did not exist.

SimonJEdwards 7 days ago in reply to FlowState

That's very helpful thanks. But what does Fast and Slow mean in terms of optimisations? What is the ideal setting to get the most optimisation?

FlowState 7 days ago in reply to SimonJEdwards

SimonJEdwards said:
But what does Fast and Slow mean in terms of optimisations?

It refers to the amount of time it takes to compile your app.

Apparently:

- basic / 1 = fastest

- fast / 2 = slower than basic

- slow / 3 = slowest of all

I think slower optimizations are supposed to be better ("more optimized"), but the tradeoff is you need to wait longer to compilation to finish.

The help for the various options in the VS Code Monkey C extension optimization setting (screencapped above) confirms this: