• Replies 4 replies
  • Subscribers 18 subscribers
  • Views 540 views
  • Users 0 members are here
Options
Related

Computational Impact

DaveBrillhart
I'm considering a minor change to my computationally demanding data fields to improve battery life and responsiveness.

When running three of my data fields, the time between calls to compute() can grow to a few seconds.

I'm considering adding logic at the start of compute() that only runs this function every 3rd time it enters the function. Since onUpdate() is also called, asynchronously every second, the compute() gate would also turn on/off a Boolean so that onUpdate() also ran every 3rd time, after compute() ran.

Thinking this would still provide me, an ultra distance cyclists, with updates frequently enough for my needs. And reduce the compute burden on the device, increasing battery life and impacting responsiveness less (especially when also running a turn-by-turn course).

Any reason why doing this would cause issues with the accuracy of the underlying device metrics?

function compute(info) {
if (loopNum >= 3) { doUpdate = true; loopNum = 1; } else { doUpdate = false; loopNum++; return; }

function onUpdate(dc) {
if (doUpdate == false) { return; }


Well it doesn't work to run onUpdate() every three seconds, because something blanks the screen! So compute() can be run every 3rd time, but onUpdate() must run every time to prevent the screen flash/blanking.
  • I'm a bit surprised the watchdog doesn't kick in and stop your DF if compute() is taking so long. While you can try to do something for your DFs, what about other CIQ DFs that are being used at the same time?
  • You can't rely on the frequency of onUpdate or compute. If you're only updating screen/computing every 3 seconds you can potentially have that if a message or notification has been displayed this area stays black after the message disappears.

    Preferably do calculations upfront if you can (intialize ?)

    Maybe you can rewrite your formula so that it becomes easier (avoid looping, use less operators if you can eg you might divide one part by a factor to then later multiply it back by another factor)?

    Maybe there are parts of your formula you only need to calculate every x seconds and still get accurate results? (you can use a loopcounter as you did, personally I would use the modulo operator on either the current unix time or on the timer in case the calculation only needs to occur when the timer is running...)



  • Instead of doing all your logic every 3 seconds, I'd look at doing 1/3 of the logic every second. That would be friendlier to other things and there wouldn't be the big hit every 3 seconds..
  • Great ideas! Jim - I'll check on my next training ride, if say, the native SPEED DF is also impacted by slower response times (updates every few seconds rather than every second). I suspect it is impacted, because I KNOW that the turn-by-turn mapping is impacted. Good idea about splitting up the logic. And some things, like sunrise/sunset processing can be done every 15 mins or so (I want to catch a timezone crossing, for example, so can't be just once a day) - thx Peter!