Optimization Guidelines

Hi everyone,
First things first: I'm new to MonkeyC, but on good terms with java and been writing for Android + Wear for some time so presumably I know the drill.
Decided to design my own full screen data field and made it run nice on simulator, but when I install it on my Forerunner 230, data field seems to lack performance during actual usage: at least timer field, which I render as two to three
separate strings depending on elapsed time value is rather quirky and most of the time seconds jump around as if there's a half-second delay, then field is redrawn several times in quick succession to make sure data is actual.

I understand that global questions like "why my code runs slow" cannot be answered, thus I ask another vague one: are there specific optimization guidelines/best practices similar to Android Wear ones such as "always prefer object property usage over variable declaration", "clearing dc every onUpdate takes much processing time" etc?

Right now my prime suspects are full screen actions like dc.clear and dc.fillRectangle, but who knows.
If someone is willing to check my code (a little bit cut to fit message limit), then it is provided below.
Sorry for the large plain text, but emulator reports increased memory footprint if I declare a lot of functions.
  • I would be surprised if there weren't different GPU's

    I would be surprised, but pleased to hear that was the case. I haven't heard any mention of it from Garmin.  I think it might have been announced by their marketing team.

  • The CIQ documentation mentions a 'graphics pool', described using low-level concepts like 'heap' and 'stack'. This doesn't necessarily imply a dedicated graphics processor (GPU). It could be a specific way of managing memory, potentially within existing hardware. As someone who has implemented GPU coding, I feel that assuming the existence of a separate GPU from this documentation might be an overstatement.

    Like I said, CIQ 4+ devices have antialiasing, alpha blending and affine transformations, other devices do not, including CIQ 3 devices such as 945 LTE which are still getting updates (including the "latest" non-AMOLED UI seen in Fenix/FR955.)

    And again, the SDK release notes (README) have references to devices with and without GPU. (Open README.html in an editor and search for "GPU". Unfortunately all the older sections are collapsed in the webpage, so it's a bit harder to search in a browser. I got the following examples by searching the source in Code and manually navigating to the appropriate sections in a browser.)

    So "officially", Garmin has confirmed that some devices have a GPU. The only open question is "which devices?" I think all the anecdotal evidence points towards CIQ 4+ devices. I think it makes sense for all the newer devices with touchscreens to have a GPU, to facilitate smoother scrolling which tracks your finger. That's my guess anyway. Another motivation might be to support AMOLED displays with higher resolution, better framerate and fancier animations.

    I used an FR630 ages ago. It had a touchscreen, but the CPU was slow (no GPU of course), and the display was very slow to respond when you swiped to change pages. And when you did swipe, content did not track your finger, but the current page abruptly changed to the next/previous page, without any kind of smooth transition.

  • I would be surprised if there weren't different GPU's

    I think it might have been announced by their marketing team.

    Why? The average customer doesn't know or care what a GPU is.

    Why do you think apple rarely talks about iphone specs, except for camera megapixels and battery life?

  • On the other hand, as an ex-Apple developer, I can assure you that the documentation for their Swift language (Apple's version of CIQ) does not make any mention of stack, heap or GPU since none of these features are accessible to the app developer. I don't understand why Garmin insists of including such similarly inaccessible entities their documentation.

  • I can assure you that the documentation for their Swift language (Apple's version of CIQ)

    Sorry to be a pedantic nerd again, but a better analogy would be that Swift is "Apple's version of Monkey C", since Connect IQ is a framework and Monkey C is a language.

    But I would probably reverse the implication and say that Monkey C is Garmin's version of Swift, since:

    - Swift came first

    - Garmin competes with Apple and not the other way around

    does not make any mention of stack, heap or GPU since none of these features are accessible to the app developer. I don't understand why Garmin insists of including such similarly inaccessible entities their documentation.

    So do you want "official" confirmation that there's a GPU or not?

    I agree that the Monkey C / CIQ documentation is often lacking, but this is the first time I've ever heard anyone complain that it has too much information.

    Note that the README / release notes I screenshotted are for Connect IQ (the development framework for 3rd-party Garmin apps), not Monkey C (the language used for Connect IQ).

    Also note that most (or all) of the 3rd party Garmin development docs are described as Connect IQ documentation. The Monkey C part of the Connect IQ website doesn't say much (or anything at all) about GPUs, based on a quick skim.

    [https://developer.garmin.com/connect-iq/monkey-c/]

    stack, heap

    They're not directly accessible, but if you aren't aware of these concepts, you can run into certain types of errors. e.g. A stack overflow can be caused by too much recursion / nested function calls, and you can run out of memory on the heap if you allocate too much memory. (Yes, I realize that Monkey C also does not directly expose the concept of "memory allocation" as part of the language, either.)

    GPU

    Well obviously the GPU has nothing to do with the Swift language, but it is an important concept in Apple *development*.

    https://developer.apple.com/metal/

    stack, heap

    Maybe it's not discussed in the Swift documentation per se, but ofc the xcode docs talk about the stack and heap, and plenty of ppl have discussed the stack and heap with respect to the swift implementation on apple devices.

    [https://stackoverflow.com/questions/27441456/swift-stack-and-heap-understanding]


    www.wwdcnotes.com/.../

    I don't understand why Garmin insists of including such similarly inaccessible entities their documentation.

    Bc any programmer worth their salt needs to understand the basic concepts of the stack and heap.

    Bc CIQ has certain features which only work with devices which have a GPU. If anything, they should explicitly tell us which devices have a GPU, since they love to drop hints about devices with and without GPUs.

    Also, it's funny that you've gone from...

    doubting the existence of a GPU in Garmin devices and saying that if they had a GPU, marketing should tell end users (who have no idea what a GPU is)

    ...to...

    insisting that Garmin shouldn't tell developers about the GPU since they can't access it.

  • And There's the heart of the problem.  I do not regard myself as a programmer.

    In 2013 I saw Jimmy Spithill lead his team onto Oracle Team USA's Americas Cup AC72 72-ft foiling catamaran in San Francisco wearing what looked like an iPhone on his forearm, and I said to myself, "I can do that". 

    And I didn't mean skippering a foiling AC72, but develop an app that could be deployed on a yacht racing tactician's wrist.

    11 years on, and the dream is a reality. I have developed raceQs running on Garmin's range of watches implementing my knowledge of what a yacht racing tactician needs and what can be delivered from GPS data, algorithms, storage technology, internet, hardware capabilities, etc., etc., etc..

    It has been a long road, and here are some of the mileposts.

    • Android phone running javascript - abandoned: phones not waterproof, hard to see the screen.
    • Pebble watch in Javascript and C - excellent results, Pebble collapsed.
    • Early Garmin watches - encouraging hardware platform but CIQ too buggy, touch screen a challenge with wet fingers. 
    • Apple watch in Swift - fabulous development environment but Apple watches not waterproof, unreadable through salty sunglasses and touch screen. 
    • Return to Garmin with improved CIQ and 5-button devices.

    So I'm not a programmer. I use the available technology to house my application. The watch development environment is only one tool in the toolset that I use to implement my application. 

    I am not a programmer.

  • I am not a programmer.

    Yep that's the problem, no offense.

    You don't consider yourself a programmer and you obviously don't want to be one, based on your present and past complaints. I think you could be one, but the desire isn't there.

    Obviously everyone has to start somewhere, but it's your choice to stop at a certain point.

    So you can't complain about development documentation being geared towards programmers. I don't see any Apple development documentation (or dev docs from any other vendor) which completely avoids talking about "programming stuff".

    Try posting in the xcode forums that the xcode debugger docs shouldn't talk about the stack and heap bc these are elements that are inaccessible to developers. Even the C spec makes no mention of a stack or heap, yet every C programmer needs to know what these are.

    And you can't complain about one thing (why doesn't Garmin tell us about the GPU?) but then pivot to the opposite complaint in the same breath (Garmin shouldn't mention the GPU bc devs can't access it.) I mean you can complain about whatever you want, but you won't be taken seriously if you complain about 2 opposite things.