Load timer

[Tearran]

Description

refinement of #326

Added a Timer function to help identify sections that are slow and may need optimization or separation to improve performance.

./tools/armbian-config-dev and ./bin/armbian-config

Initializing script: 0 seconds
Setting base data: 0 seconds
The current Armbian 24.8.4 stable (bookworm) is supported.: 4 seconds
Loaded Runtime variables...: 0 seconds
Loaded Dialog...: 0 seconds
Loaded Docs...: 0 seconds
Loaded System helpers...: 0 seconds
Loaded Network helpers...: 0 seconds
Loaded Software helpers...: 0 seconds

note '--api' '--docs' and '! -t =$0" do not output timer results see

./bin/armbian-config --api set_checkpoint help

Usage: set_checkpoint <start|stop|mark|show> [description] [show]
Commands:
  start              Start the timer.
  stop               Stop the timer.
  mark [description] [time] Mark a checkpoint with an optional description and an optional flag to show the output.
  show               Show the total elapsed time and checkpoints.

Issue reference:
[Bug]: sanitize_input #324
function raceing
Partly addresses UX vs Non interactive mode use

Implementation Details

• added variable checks for UX mode to help separate from the non interactive modes

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have ensured that my changes do not introduce new warnings or errors
• No new external dependencies are included
• Changes have been tested and verified
• I have included necessary metadata in the code, including associative arrays

[dimitry-ishenko]

@Tearran IMHO it would be PITA to maintain two copies of armbian-config.

What about using an env var (eg, ARMBIAN_CONFIG_DEBUG or just DEBUG) to show the timing info? Eg,

DEBUG=1 ./bin/armbian-config ...

Then in message_checkpoint.sh you can add something like this at the end:

# disable set_checkpoint if DEBUG has not been defined
[[ -n "$DEBUG" ]] || eval "set_checkpoint(){ :; }"

[igorpecovnik]

IMHO it would be PITA to maintain two copies

Yes, I would also propose to have one.

[dimitry-ishenko]

@Tearran I was under the impression that we only wanted timing info for debugging purposes. I kinda like that it's printed every time, but I don't know if there might be objections in terms of performance or some other reasons.

[dimitry-ishenko]

FWIW can be replaced with:

unset UXMODE
[[ -t 0 && "$1" =~ ^(|--cmd|--help)$ ]] && UXMODE="true"

[dimitry-ishenko]

Missing indent? Same for other cases.

[dimitry-ishenko]

Missing indent inside for-loop?

[dimitry-ishenko]

Nitpick, but if you do this, you can avoid unnecessary calculations in non-UX mode:

	mark)
		if [[ "$UXMODE" == "true" ]]; then
			local checkpoint_time=$(date +%s)
			local checkpoint_duration=$((checkpoint_time - set_checkpoint_PREV))
			set_checkpoint_PREV=$checkpoint_time
			set_checkpoint_CHECKPOINTS+=($checkpoint_time)
			set_checkpoint_DESCRIPTIONS+=("$2")
			local count=${#set_checkpoint_DESCRIPTIONS[@]}
			[[ "$3" == "true" ]] && printf "%-30s %10d seconds\n" "$2:" "${checkpoint_duration}"
		fi
	;;

[Tearran]

What about using an env var (eg, ARMBIAN_CONFIG_DEBUG or just DEBUG) to show the timing info?

@dimitry-ishenko I am not opposed to using a DEBUG environment variable in general. However, I would like to clarify that the messages displayed are not meant for debugging purposes and are not being introduced with this PR. These messages were previously implemented to improve the user experience by indicating that the application is working and not frozen.

In other words, this PR does not address bugs. Rather, it outlines the expected parsing load time limitations due to the linear nature of bash, such as function variable racing and other inherent constraints.

The addition of the timestamp is multifaceted. Firstly, IMHO it is important to recognize the limitations of bash, so that expected limitations are not identified as bugs. Showing loading time addresses this by clearly showing expected behavior. For example, 4 seconds may be undesirable but it is not a bug. By providing these user-facing messages, we aim to enhance user experience by transparently communicating the application's activity, thus avoiding any misconceptions of the application being unresponsive.

[dimitry-ishenko]

@dimitry-ishenko I am not opposed to using a DEBUG environment variable in general. However, I would like to clarify that the messages displayed are not meant for debugging purposes and are not being introduced with this PR. These messages were previously implemented to improve the user experience by indicating that the application is working and not frozen.

@Tearran sorry, not sure why I got the idea this was for debugging. Thanks for the clear explanation, it makes sense.