Best practices - performance, memory management, optimization

Can you please share what your best practices are in terms of

Memory management and
Optimization for performance

I have now had two users providing feedback that my watchface slows down the watch overall.
For example apparently when the user wants to start training and pressing start / stop takes a moment to appear, or nothing happens and the user has to click twice. Apparently shows with other functions also.

Doesn't the watchface completely unload and free up memory when the user performs actions outside the scope / view of a watchface?

The description above does not make sense to me, but I believe that since it has been reported, I need to investigate at least.

For starters I am going to try and load resources a bit smarter. I know that I load all various bitmaps for example different battery levels all at once in the onLayout. But I might just need to load just the singel one on every onUpdate.

Regards,

H
  • Is there any chance this is not a memory problem, but related to the issue described in the post below where button presses or swipes are missed when starting and stopping activities? AFAIK, this bug hasn't been fixed yet. When I first observed the bug, it seemed like the watch was just slow, but it's definitely a consistently missed action related to activity starting and stopping.

    I've only observed the bug in watch apps, but I imagine it could manifest itself in other places.

    https://forums.garmin.com/showthread.php?236436-CIQBUG-Session-stop-causes-future-key-press-to-be-lost
  • Is there any chance this is not a memory problem, but related to the issue described in the post below where button presses or swipes are missed when starting and stopping activities? AFAIK, this bug hasn't been fixed yet. When I first observed the bug, it seemed like the watch was just slow, but it's definitely a consistently missed action related to activity starting and stopping.

    I've only observed the bug in watch apps, but I imagine it could manifest itself in other places.

    https://forums.garmin.com/showthread.php?236436-CIQBUG-Session-stop-causes-future-key-press-to-be-lost


    Thanks for the link and background.

    Unfortunately I cannot tell as I don't have the device (fenix3) where the issue was reported.
    But it sounds consistent with what you have described.

    I will keep looking in my watchface. I anyway do believe that there need some cleanup to be done regardless.
  • Is memory management automatic?

    How do I release / manage memory in Monkey C?
  • Memory management is automatic in MonkeyC.

    function test() {
    // allocate array of 100 objects
    var x = new [100];

    // x will automatically be deallocated here...
    }


    That said, you can explicitly manage the lifetime of that memory if you want.

    function test() {
    // allocate array of 100 objects
    var x = new [100];

    // you can deallocate the memory explicitly like this
    x = null;

    // you can do more stuff with more memory available
    }
  • I still don't know why the watch VM keep telling CIQ_LOG I have unfreed memory in exit. :-( but app is working fine.
  • I still don't know why the watch VM keep telling CIQ_LOG I have unfreed memory in exit. :-( but app is working fine.


    This sounds like it's a problem in the VM itself. What all in in CIQ_LOG.txt?
  • I still don't know why the watch VM keep telling CIQ_LOG I have unfreed memory in exit.


    This can happen if you have circular references. i.e., A has a reference to B, and B has a reference to A. The simulator should tell you if this is happening when you exit your app (assuming you're using 1.1.2 or later).

    Travis
  • CIQ_LOG tells me nothing useful except - Unfrees memory on exit
    Simulator also tells me nothing. 1.1.3

    So, CUQ guys say - don't sweat it. But... It's a little disheartening to see it.
  • Former Member
    Former Member over 9 years ago
    This message is supposed to indicate that you have a circular memory reference (as described by Travis). There have also been some VM issues that can cause this error to come up when it shouldn't if the app crashes. If your app is exiting cleanly and showing this message, you probably do have a circular reference.

    There are situations where you may want to use a circular reference when you want two objects to reference each other. There is usually a way to avoid the circular reference, but it might be simpler to implement with one.

    Circular references can cause you issues if you aren't careful with them, which is why the error message is logged. You can leak memory from the app space if you aren't careful.

    For example:
    function leaksMemory() {
    var A = new myObj();
    var B = new myObj();

    A.reference = B;
    B.reference = A;
    } //The memory used by objects A and B is lost and cannot be recovered until the app exits.


    If you use a circular reference intentionally, then you need to break the chain before you drop your own references.

    For example:
    function leaksMemory() {
    var A = new myObj();
    var B = new myObj();

    A.reference = B;
    B.reference = A;

    //Do some stuff here with these objects

    A.reference = null; //This breaks the circular reference
    } //The memory used by objects A and B is freed here because the reference has been removed.


    You can use the memory inspector added in the 1.1.2 release to check for circular references in the simulator. If you do not see any reported in the simulator, we can take a look at your app to investigate the possibility of a VM error triggering the error message when it should not be.
  • This message is supposed to indicate that you have a circular memory reference (as described by Travis). There have also been some VM issues that can cause this error to come up when it shouldn't if the app crashes. If your app is exiting cleanly and showing this message, you probably do have a circular reference.

    There are situations where you may want to use a circular reference when you want two objects to reference each other. There is usually a way to avoid the circular reference, but it might be simpler to implement with one.

    Circular references can cause you issues if you aren't careful with them, which is why the error message is logged. You can leak memory from the app space if you aren't careful.

    For example:
    function leaksMemory() {
    var A = new myObj();
    var B = new myObj();

    A.reference = B;
    B.reference = A;
    } //The memory used by objects A and B is lost and cannot be recovered until the app exits.


    If you use a circular reference intentionally, then you need to break the chain before you drop your own references.

    For example:
    function leaksMemory() {
    var A = new myObj();
    var B = new myObj();

    A.reference = B;
    B.reference = A;

    //Do some stuff here with these objects

    A.reference = null; //This breaks the circular reference
    } //The memory used by objects A and B is freed here because the reference has been removed.


    You can use the memory inspector added in the 1.1.2 release to check for circular references in the simulator. If you do not see any reported in the simulator, we can take a look at your app to investigate the possibility of a VM error triggering the error message when it should not be.



    The simulator (I'm using 1.1.3) does not tell me anything. Usually if a circular is detected, the sim will either crash / tell me there is a circular and give me a shot of the last memory snapshot before the crash.

    I have prev sent the app in question for you guys to look at, if not mistakem - the answer was no issue.
    I can send it in again as I've reduced the code and optimized it further to use lesser memory.