• State Verified Answer
  • Replies 5 replies
  • Subscribers 16 subscribers
  • Views 862 views
  • Users 0 members are here
Options
Related

Memory consumption and settings. A general question.

9635560
over 5 years ago

I have two DFs using near identical code; the _ONLY_ difference in the code base is a Boolean toggle to change the value of "key" when doing app.getProperty(key).

On one of them, a single sport variant, the settings file has a single set of properties. On the other, which provides sport-specific settings, the settings file has a set of properties for each of the four HR_ZONE_SPORT_ constants (generic, run, bike, swim).

But...

The multi-sport version crashes out due to memory, where the single-sport version runs perfectly.

Ok, so a simple and very obvious cause... when I profile the memory:

My MAHOOSIVE settings files for the multisport are adding several hundred KB to the settings dictionary...

MY QUESTION!

Why does Garmin need to load and store the entire settings dictionary in memory when I only read it during initialize() ?

Surely, it should be an "on-demand" load in much the same way as JSON resources and String resources are?

G

  • 0 over 5 years ago

    Settings are always in memory.  There are really only two times you need to read them - start-up and onSettingsChanged.  But many apps read them all the time (each onUpdate()).

    Settings aren't loaded by key, but as a chunk.  When you change settings in a running app, it also needs to load the new settings and merge them with what's already loaded, so you'll see peak memory increase.

  • 0 over 5 years ago in reply to jim_m_58
    jim_m_58 said:
    Settings are always in memory.

    I can see what you mean!

    I had always assumed that it was loaded on demand as there are so many threads saying it is inefficient to call getProperty() during onUpdate etc. - the received wisdom being that you get it out of the way and forget about it.

    However, if getProperty is simply reading a dictionary that is already in memory, then quite a lot of my calculus on memory savings changes.

    For example, rather than reading stuff during initialize(), is there really no performance hit to reading _EVERYTHING_ on the fly, as needed?

  • 0 over 5 years ago in reply to 9635560

    The problem with loading them on demand is file system access on the watches is really slow.

    That is what happens with Application.Storage, so you want to be really careful when you read/write from there.

  • 0 over 5 years ago in reply to jim_m_58

    Ok, I am confused now! I'm misunderstanding what you are saying, I think.

    jim_m_58 said:
    Settings are always in memory. 

    Implies they are already loaded, no file system access as not reading them.

    jim_m_58 said:
    The problem with loading them on demand is file system access on the watches is really slow.

    But this implies the opposite, surely?

    ETA: By "no file system access" I obviously mean after the first time!

  • +1 over 5 years ago in reply to 9635560

    Settings are loaded when the app starts and again if they change (before onSettingsChanged() is called in an app) (and if I recall, saved to the file system when written by an app.  But as a whole - not individually.

    So in the simplest case they are loaded into memory when the app starts (as a whole.  Not loaded per key.).  Same way the app itself gets loaded when it starts.  And not read from the file system again.  Only a single file system access.  "on demand" would be hitting the file system for each key, when ever a setting is read.