-
-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load timer #405
base: main
Are you sure you want to change the base?
Load timer #405
Conversation
@Tearran IMHO it would be PITA to maintain two copies of What about using an env var (eg,
Then in # disable set_checkpoint if DEBUG has not been defined
[[ -n "$DEBUG" ]] || eval "set_checkpoint(){ :; }" |
Yes, I would also propose to have one. |
remove redundant file
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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 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. |
@Tearran sorry, not sure why I got the idea this was for debugging. Thanks for the clear explanation, it makes sense. |
bin/armbian-config
Outdated
|
||
[[ -d "$script_dir/../tools" ]] && tools_dir="$script_dir/../tools" | ||
[[ ! -d "$script_dir/../lib" && -n "$tools_dir" ]] && die -e "Please run\nbash "$tools_dir/config-assemble.sh" to build the lib directory\n" | ||
|
||
|
||
DEV=$([[ "$(basename "$0")" =~ .*"-dev"$ ]] && echo "true") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[[ "$(basename "$0")" =~ -dev$ ]] && DEV="true"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears I must have been really indecisive about that one or the subshell and then .. squirrel .. Thank you for catching that. Line 27 Subshell FTW I presume? :) but really my be best to drop $DEV stuff from this PR for now
your DEBUG=1 ./bin/armbian-config
suggestion A+
no need to apologize, Debugging is a reasonable conclusion; the |
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
./bin/armbian-config --api set_checkpoint help
Issue reference:
[Bug]: sanitize_input #324
function raceing
Partly addresses UX vs Non interactive mode use
Implementation Details
Checklist