How next items count into watch face memory limits

How to optimize the memory storage so the watch has the most memory available in background that fails to exit when it runs out of memory?

Let's say a variable A eats 1 memory , item B eats 100 memory units

How much from the quota available in the watch's background process eats:

A/B stored by App.getApp().setProperty
A/B stored by Storage.setValue
how does it differ when using char 'c' vs string with length of ten like "string-10" as an identifier

Sys.getSystemStats().freeMemory gives pretty chaotic measurements.

It seems like setProperty is not the eating memory, setValue eats 32B just when used for the first time, and size of keys don't matter.

Is that correct assessment of the behavior?

What is the best approach to conserve the most memory for the background process while having couple of big arrays and many small settings to store?

jim_m_58 over 4 years ago

Not sure I understand, but remember in a background Service, setProperty() and setValue() are not available on all devices. You might seeing what looks like you're out of memory when used on devices that don't support them. The background service will crash.

When you set up a background Service, AppBase is included even if you don't have the background annotation for it. Things with the annotation are also included, as are globals. (the background has it's own copy)

Not sure why freeMemory isn't working for you. It's always worked fine for me.

myneur over 4 years ago in reply to jim_m_58

I did the measurements in app. More importantly by those measurements both setProperty and serValue don't eat watch's memory. Is that a right assessment or is this measurement somehow flawed?

The reason I mentioned the Background was that I'm looking for best way to optimize storage to make it available for it, because the memory in the Background is even more limited and Background.exit easily hits the limits even when there are 3k memory left there.

I can rephrase the question not to make confusion with the background as:

What is the best approach to conserve the most memory while having couple of big arrays and many small settings to store?

FlowState over 4 years ago in reply to myneur

I can't speak to background processes (don't use them), but in my experience, setProperty() and/or app settings are pretty heavyweight (memory-wise) because the app loads all of your properties into a dictionary on startup, whether you read them or not.

So:

- Longer property names consume memory

- Additional properties consume memory

I checked with my one app that uses Application.Storage, and it looks like at least some of the data is loaded into a cache at runtime (also a dictionary).

I'm guessing (but not sure) that this cache doesn't always have *all* of your storage loaded into memory, given that some devices apparently have much more app storage than available ram for apps. (e.g. The app storage capacity for Fenix 6 Pro is apparently 10 MB.)

So it's possible that using Application.Storage at least has the potential to save memory compared to Properties. I haven't done proper apples-to-apples testing tho.

jim_m_58 over 4 years ago in reply to FlowState

with properties associated with settings there's the memory used at runtime, but you'll also see a memory peak if app settings are changed while the app is running (say looking at the WF and changing colors) while the old and new are being merged.

With Application.Storage, memory used is really based on the size of the key+size of it's data. A single key/data can actually be as large or larger than the old ObjectStore

FlowState over 4 years ago in reply to jim_m_58

Right but there's also the size of the Storage *cache*, which can have multiple keys. I have no idea how that memory is managed by CIQ, since I don't use Storage much (and the app I use it in never gets close to running out of memory.)