4

Can we have the option to view run log time down to the MILLISECOND, instead of just to the second?

A lot of the time I have tasks that I would like to time-optimize.  I would like to know which actions in the task are the slowest ones.  It would greatly improve my judgment to know how slow each action is in my tasks.

The run log shows us the time each action happened, but sadly it only tells us the time down to the second.  NOT to the millisecond.

PLEASE allow us to enable more exact timestamps to be shown on the run log.  For users like me who want a better understanding of each action's latency, this is crucial.  At the moment, the only way for me to know is to painstakingly record the current TIMEMS, find the difference between it and the last time it was recorded, and print/save that number somewhere.  (And just performing that check between my actions just adds more time to the task anyway, skewing the results; not to mention how unwieldy it makes reading my tasks!!)

It is so frustrating setting that up and cleaning it up later.  Please can you allow us to view milliseconds in the run log?

Follow

1 reply

Votes Newest Oldest

The run log is already crowded. Can you elaborate why using TIMEMS to benchmark tasks/actions is not suitable? Surely you can just run the task manually, flash the resulting millisecond duration, then remove all the timing-related actions? They don't need to remain present in your task for the long term once you've already seen how long it takes?

Comment
T

Hi Richard--I actually already wrote why TIMEMS as a benchmark is so conflabbit unwieldy!

"At the moment, the only way for me to know is to painstakingly record the current TIMEMS, find the difference between it and the last time it was recorded, and print/save that number somewhere.  (And just performing that check between my actions just adds more time to the task anyway, skewing the results; not to mention how unwieldy it makes reading my tasks!!)"

When I am trying to optimize performance, I like to measure the speed of many actions.

1. Performing these benchmarking actions between my actions will skew the results, since the mere act of recording/measuring itself with extra actions adds extra latency.

2. Adding these checks is UGLY AS SIN! It makes my tasks HIGHLY unreadable because they get SWALLOWED by benchmarking actions.

3. It takes a lot of time and attention to insert these actions, and even more to later find and remove them.

4. The runlog is the natural place where this info is stored and it already shows the timestamps.  All I'm asking for is the option to view the milliseconds.

I think you have a great point that the runlog is already cluttered, but this is a very important feature for people like me who aim to optimize tasks that are running repeatedly and its inclusion is definitely warranted at least as an option.

Thomas, I did read all that in your post, sorry if it seemed like I didn't. What I don't understand why you feel the problem is so severe. Are you putting an action to save %TIMEMS inbetween every other action in the tasks you are profiling? I can understand you describing that as 'swallowing' the other actions. Maybe just saving the TIMEMS at the start and end of the task would be sufficient? If any one action is significantly slower than the rest this should be obvious when running the task in the task edit screen.

Also be careful of over-optimising. I have a fairly slow device (a four year old mid-ranger) and it actually runs my fairly heavy Tasker setup just fine. In my experience unless you use for loops over long lists, nothing really takes that long.

I'll close by saying that I'm not averse to adding ms into the runlog. I actually strongly favour the whole runlog UI being rewritten, perhaps to including a toggle to show time in millisecond precision. Maybe you agree and would vote up some of these suggestions for runlog reform:

https://tasker.helprace.com/i115-enhanced-run-log
https://tasker.helprace.com/i12-give-the-runlog-action-the-option-to-only-effect-the-current-task
https://tasker.helprace.com/i151-runlog-better-identification

Reply