Cost of "Request sensors and stats"?

[TapioOfTapiola]

I was always wondering, if extensive use of (subject) is expensive on cpu/battery or totally harmless...? What if I have the idea to check many data every 5 seconds? Does it make a difference if I get only is_track_rec_recording, or 20 others at the same time?

Just wondering. I am always very conservative in my scripting, but maybe you know that pulling data is negligibly cheap...

thx

[TapioOfTapiola]

In other words, if it was as cheap as e. g. a single "variable set", I wouldn't have to think about it any more...

[Falcosc]

Request sensors and stats maybe is expensive. Locus can only send all or nothing. For that reason I do cache the result for 1000ms.
So in reality you are fine with executing it multiple times.

But I don't know how expensive it is to process the Fields in Tasker. I give tasker the requests key value pairs and don't know how much stuff does happen to them.

You should benchmark is to find the real numbers. It could be that Tasker does take 20 times more CPU cylces and Locus Maps does take 10 times more CPU Cycles then the request sensor task.

Just collect the Process ID from Tasker, LocusMaps and the plugin. (Tasker may have multiple Process IDs, you need to check what happens during Task execution)
And with the Process IDs you can collect the used CPU cycles in User time and System Time.
/proc/<PID>/stat

I did this to check why I couldn't reach my benchmarked battery runtimes in the real word: https://help.locusmap.eu/topic/cpu-time-increase-after-long-runtime

[TapioOfTapiola]

Impressive testing, will read your findings. I noticed you also wished for "set map via preset". This was a topic a few weeks ago, Menion is almost convinced, problem is, he sees Maps as data, not settings..
Aber er wackelt, will er später entscheiden, vielleicht kannst Du ihn nochmal kneifen 😁

[TapioOfTapiola]

So yeah, does Locus do any map rendering if I just started recording via an intent? In that case, setting a blank map via preset would be even more interesting for me.

[Falcosc]

I did consider switching to IntentService https://tasker.joaoapps.com/pluginsservicesmigration.html
As it turns out, it is only useful if tasks are long running and parallel execution support without blocking configuration UI is needed,

I did some benchmarks and here are the results
Broadcast Receiver:

• ~1ms to read request and return values in variables
• ~35ms call and retrieve plugin data in Tasker with 3 paramters
• ~35ms overhead

IntentService:

• ~6ms to read request and return values in variables
• ~60ms call and retrieve plugin data in Tasker with 3 paramters
• ~65ms total overhead

Sound not so bad, but let's pit these values in context:

• 25ms to download 90 Locus Maps values for "Request sensors and stats" and return 2 of them
• 1ms to return 2 "Request sensors and stats" values from cache (up to 990ms after last download)
• 50ms download 11.000 trackpoints and process 55.000 values and return 200
• 3ms to return next 200 of these 11.000 trackpoints with 5 values each

You need to add either 35ms or 65ms overhead to each of them to get the total time

So I will not switch to IntentService.

But only plugin tasks are slow with 35ms or 65ms overhead
Internal Tasker Task actions are fast:

• ~5ms total inkl overhead to set a value to variable

I tested 10 task actions each while checking only 2nd to last times to exclude starting overhead and use the time between 2 intents as a sum of pre-processing and post-processing overhead.
Times from emulator match to real hardware of my old android 7 phone. Real hardware of 4 generation newer phones is of course much faster.