low memory issues with a multicock variant

You are reading a single comment by @HughB and its replies. Click here to read the full conversation.

•

HughB

I do however have an odd performance issue with one of the Apps.

I have a compass app based on the Magnav code. I use the same compass code in Waypointer and Arrow. All of these compass apps start to run slow after a while and become unresponsive to BTN3 presses. I have been trying to track down the issue.

I am wondering if the following approach is an indicator of performance.
Set a timer for a known time
Record the time using getTime
Then check that the time against the expected time.

    
    function startTimer() {
      draw();
      readCompass();
      intervalRefSec = setInterval(readCompass, 200);
      tPerf = getTime();
      intervalPerf = setInterval(perfCheck, 1000);
    }


    function perfCheck() {
      var tNow  = getTime();
      var tDiff = 1000*(tNow - tPerf) - 1000;
      tPerf = tNow;
      console.log("perf=" + tDiff);
    }

If all is good you would expect the timer to come in close to the expected number of milliseconds. In this case if the diff is greater than 1000ms then the timer was delayed.
Sometimes I am seeing this sort of output.

>
 ____                 _
|  __|___ ___ ___ _ _|_|___ ___
|  __|_ -| . |  _| | | |   | . |
|____|___|  _|_| |___|_|_|_|___|
         |_| espruino.com
 2v08.187 (c) 2019 G.Williams
perf=2.01586914062
perf=-0.63916015625
perf=0.06274414062
perf=-0.08984375
perf=0.0322265625
perf=-0.02880859375
perf=0.00170898437
perf=0.0322265625
perf=140.07739257812     <<<<=== LCD times out, have to BTN3 press
perf=1.7412109375
perf=0.06274414062
perf=-0.02880859375
perf=-0.02880859375
perf=0.00170898437
perf=0.00170898437
perf=0.00170898437
perf=0.154296875
perf=-0.08984375
perf=1.77172851562
perf=0.0322265625
perf=-0.02880859375
perf=0.00170898437
perf=1.52758789062
perf=-1.52416992187
perf=0.00170898437
perf=1794.40478515625    <<<<=== LCD times out, have to BTN3 press
perf=335.90869140625    <<<< now we see 300+ms delays on a 1000s timer
perf=363.13037109375
perf=346.37622070312
perf=1860.96362304687
perf=432.55786132812
perf=427.15625
perf=443.17797851562
perf=338.38061523437
perf=355.68408203125
perf=364.16796875
perf=443.30004882812
perf=443.78833007812
perf=1974.03125
perf=414.91870117187
perf=431.39819335937
perf=421.87670898437
perf=419.43530273437
perf=433.10717773437
perf=364.13745117187
perf=336.15283203125
perf=341.79858398437
perf=442.537109375
perf=398.4697265625
perf=399.53784179687
>
>

The above is a lucky example, it does not usually happen with the screen going off (I think that is cooincidence here). I can keep the screen on by pressing BTN3 before it goes off and sometimes I will see this.

If feels like something else is grabbing resource.

Kind of need the equivalent of the unix uptime command to see how loaded the CPU is.

•

Robin in reply to @HughB

Wed 2021.03.10

'In this case if the diff is greater than 1000ms then the timer was delayed.'

Hugh,

I'm not sure I'm 100% with what is attmepted here, but as getTime() returns consecutive incrementing floating point values,

http://www.espruino.com/Reference#l__global_getTime
'Return the current system time in Seconds (as a floating point number)'

why not place one inside the setInterval() at L7 and print that to the console?

That should help narrow down if the perfCheck() loop functions as expected.

Haven't tested, but if less than 1000msec then they should toggle, e.g. L7 :: L15, and on a delay the console should just update each 1000msec e.g. L7 only. Also time stamping inside perfCheck() should also coincide with L7

Would setTimeout() as it fires just once be a better choice?

https://www.w3schools.com/jsref/met_win_settimeout.asp

low memory issues with a multicock variant

About

Espruino