• State Not Answered
  • Replies 2 replies
  • Subscribers 20 subscribers
  • Views 583 views
  • Users 0 members are here
Options
Related

Accessing system info and properties on every update vs pre-loading them.

Joe Berger

I'm sure if this topic has been discussed, but I can't find definitive answers, or the answers are very old. Since we have no tools to measure CPU load - this question is for our Garmin insiders, like Travis and Brandon (maybe others who have this info).

I'm preloading all app properties onSettingsChanged, and loading Activity, System, ActivityMonitor and other system-related info into local vars just once per update or per a change of settings to avoid CPU load for every piece of data I'm displaying in the watch face.

The problem is - that uses a lot of memory.

I understand that to free up the memory I have to remove all those private vars and reference global objects on the fly.

The question is - how does it impact the CPU/battery load? Is there a measurable difference between accessing a private var vs. Application.getApp().getProperty?

Also, loading ActivityMonitor.getInfo() into a private var once and using that var N times vs. calling ActivityMonitor.getInfo() N times?

Thank you! 

  • 0

    I've never been 100% clear on whether getProperty() is always a filesystem access or whether it could also be a RAM access, considering that the app settings/property dictionary takes up memory, too. But IIRC the advice I've seen in this forum is to not call getProperty() regularly.

    I can't answer your question about whether calling things like ActivityMonitor.getInfo() have a *significant* impact on battery life or not, but if you think it matters and you want to have your cake and eat it too, you could save all your persisted data to the most compact data structure possible: a bit-packed array of numbers (32-bit integers).

    e.g. Instead of:

    var x = ...; // number between 0-255

    var y = ...; // number between 0-255

    var z = ...; // number between 0-65535

    you would have

    var data = [ z << 16 | y << 8 | x, ... ];

    // to access x, y and z later

    var z = data >> 16;

    var y = (data >> 8) & 0xFF;

    var z = data & 0xFF;

    Of course the downside is you do waste some memory on the code to encode/decode this stuff, and of course you'd use CPU cycles on the encoding/decoding itself. Plus it would be harder to understand and maintain. Probably not worth it. (But it's a great strategy if you have lots of hardcoded data which will absolutely not fit otherwise. Probably more applicable to data fields, especially on old watches or current watches which only have 32 KB for data fields.)