• Replies 9 replies
  • Subscribers 18 subscribers
  • Views 1561 views
  • Users 0 members are here
Options
Related

Adding one property then <Application Settings> memory size increases by 7kB!

markdotai
Eclipse IDE for Java Developers (running on Windows 10 PC)
Version: 2018-09 (4.9.0)
Build id: 20180917-1800

With Connect IQ SDK 3.0.8 running the app in the simulator.

I have been working on a Watchface app and have run into a problem where if I add one extra property then suddenly the current running memory usage (on the simulator) increases by about 7kB. The property does not even need to be linked to a setting for this to occur.

Looking at the memory view in the simulator it shows the memory size of <Application Settings> has changed from 2384 (which I normally see) to 9404 - which would on its own explain the 7k jump in memory usage. So I suspect there is a bug occurring here.

Unfortunately the sudden increase of 7kB memory usage pushes my Watchface app over the edge and prevents me changing settings via the App Settings Editor as the peak memory becomes too high for it to also load in a new set of settings.

I have replicated the problem with a completely fresh new project following these steps:

I created a new project and made a Watchface for 3.0.x of type "Simple With Settings" for Fenix 5X Plus.
Then I edited the properties.xml file to make there be 102 properties (see attached file).
When I ran it in the simulator then <Application Settings> memory size (in the simulator memory view) was 2384.
I added one more property to make 103 and ran it again.
The <Application Settings> memory size was now 9404.

But things get slightly weirder.
Running it again with 103 properties the <Application Settings> memory size was back down to 2384!
Increasing properties one by one it stayed like this until 112 properties.
Then at 113 properties the <Application Settings> memory size jumps to 9404 again.
It now repeats every time switching between 112 & 113.

So there is something odd going on.

Hope you can fix this problem as suddenly losing 7k of memory is a lot when close to the edge already!
  • Did a quick test with your xml file and I did see the issue you're describing. I will make a ticket! Thanks
  • Former Member
    Former Member
    In general this is a completely normal behavior for a hash, but there does seem to be something potentially strange going on here.

    The effect you are seeing is a rehash that is occurring when the load of the exiting hash exceeds the load factor (https://en.wikipedia.org/wiki/Hash_table#Dynamic_resizing)

    Hashes in our system should approximately double the space they require each time the load factor is exceeded. The strange thing here, is that it appears to be skipping a size. As best I can tell, there should be a container size of 5120 bytes in between the two sizes you are getting.
  • Did a quick test with your xml file and I did see the issue you're describing. I will make a ticket! Thanks


    Great, that is good to know, thanks :-)
  • In general this is a completely normal behavior for a hash, but there does seem to be something potentially strange going on here.

    The effect you are seeing is a rehash that is occurring when the load of the exiting hash exceeds the load factor (https://en.wikipedia.org/wiki/Hash_table#Dynamic_resizing)

    Hashes in our system should approximately double the space they require each time the load factor is exceeded. The strange thing here, is that it appears to be skipping a size. As best I can tell, there should be a container size of 5120 bytes in between the two sizes you are getting.


    Thanks for that info. Hopefully that means for my case the memory usage will get reduced, but not down to the level with one less property. I'll have to do some testing once a fix is hopefully made so I can see how it's working at that point. And then come up with a plan for how many properties I can use!
  • markdotai - have you tried this on a real device? The reason is if it happens on the device too, it won't be just getting a new SDK, but the FW on the device will also have to be updated, and based on the devices you use and if doesn't work on those, it could take some time for them all to be updated. If you support devices using CIQ1 or CIQ2 it could take a very long time, as they don't get new FW that often


  • Given the nature of the bug, I'd expect to see it on devices and the simulator.
  • markdotai - have you tried this on a real device? The reason is if it happens on the device too, it won't be just getting a new SDK, but the FW on the device will also have to be updated, and based on the devices you use and if doesn't work on those, it could take some time for them all to be updated. If you support devices using CIQ1 or CIQ2 it could take a very long time, as they don't get new FW that often




    I haven't checked this memory usage on a real device - I hate to say it but I haven't worked out how to get log data back from my watch yet! So far I have just copied the app to my watch to test it and it has always worked so far - but then I can't change settings on my watch (which would cause out of memory) as I haven't yet published the watchface on the store.



    That's useful to know about requiring a new device FW as well. I am only planning on supporting some of the newest devices which are on CIQ3, so that should be ok for me.



    Thinking about it overnight I will try reducing my number of properties as well. It won't be so nice for the user to create their settings, but I think it will be ok.



    I did notice something last night which seems related to this. I started my watchface in the simulator and <Application Settings> was at 2384 size (my number of properties was below the limit which causes the memory jump). Then I sent some new settings from the Application Settings Editor. I don't think this created any new properties, but I was surprised to see that afterwards <Application Settings> was now at 9404. Was this just something left over from having the old and new settings loaded at the same time while they were copied over? Or I had just added some code to write some values to Storage so maybe that is connected.
  • Even if you're just using CIQ 3.x.x devices, the FW can come out at different times - the f5/935 devices at one time, the f5+ devices at another, and the 645 devices at yet another. Then you have the APAC (Asian- Pacific) variants of devices that lag the ROW (Rest of World) devices by a month or more. So maybe look at setting a minimum SDK for your app when the change starts to make it to devices if you are using it.

    As far as capturing stuff like this on a device, I have two methods.

    One, is that I just hijack one of bits of data that's displayed on the screen and use that to display my debug info, or I add Sys.println() calls to the code, and create a garmin\apps\logs\<myappname>.txt file. I use the 1st if I want to keep an eye on something that keeps changing, and the log file if I have things I want to see at specific points in time (memory at start up/after onSettingChanged, for example)

    For testing with settings, marking an app as "beta" in the store is really handy. Only you can see it/downloading it, but you can change settings for testing.

    This App is for Testing Only
  • Nice, I didn't know about the beta app feature - I'll have to get that going asap :-)