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

Unexplainable power delegate results. Is it a Garmin error?

Mark Bolusmjak

I have an onPartialUpdate implementation that I've benchmarked in the profiler to be quite fast (less than 1ms on average).

I'm also manually tracking max/average (via System.getTimer()) and getting average speeds of 0 or 1ms, and max of 4ms (in agreement with the profiler).

If I run the code long enough, suddenly my power delegate is tripped up with a 

executionTimeAverage 915.913635

That disagrees with the average that I'm tracking, which is so low it's 0-1ms.

For a measurement to affect the average so drastically, (e.g. after seeing 200 samples of sub 1ms times), I'd need a sampled value of over 3 minutes. That did not happen. I was watching and 3 minutes did not pass by.

Note that this trips up hardware too. So, hardware and sim claim that onPartialUpdate averages 900+ms, while manual benchmarking and profiling suggest 1ms. 

So what might be going on?  And how might I track down the cause?

  • 0

    Instead of using things like getTimer(), have you used "View watchface diagnostics" in the sim?  When you have the watch face running in low power, you can see the actual value.  1ms is not correct,  Also, you don't want to do anything in onPartialUpdate that accesses the file system, like loading resources, etc.

    Here for example is one of mine, in low power mode. About 11ms

    Things will look fine in the sim for a minute, then onPartialUpdate won't be called any more if you exceed the avg power budget of 30ms

    Here's another one of mine, under 6ms, but I have a really small clip region.  Just the seconds:

  • 0 in reply to jim_m_58

    Thanks. The watchface diagnostics *during* low power mode gave me some insights. I can clear it up. When you say don't do stuff that "accesses the file system, like loading resources", do you mean not very often? Or NEVER?

    To me it seems like the word "average" in "executionTimeAverage" indicates that on occasion you can go over the limit, so long as it isn't often.

  • 0 in reply to Mark Bolusmjak

    In onPartialUpdate, never.  That alone will cause the power budget to be exceeded.  Accessing the file system is expensive.

    Consider an analog WF.  With clip regions, things are updated by row.  The more rows, the longer it takes.  So when the second hand is at 3 or 9, very few rows, while at 6 and 12, many rows.  So the avg between the two cases must be under 30ms.