akinomyoga
commented
1 month ago In general, ble.sh needs to perform many things behind after receiving RET until it starts the execution of the command. Also, if you refer to the time Starship reports, it also contains the time of the command execution and subsequent other processing (including calling Starship to evaluate the next prompt). How much time ble.sh takes to process each of them depends on the machine and the detailed setup.
In addition to what ble.sh processes internally (such as the display of the last prompt, the command history management, and preparation of the context for the user's command), some external factors are the invocation of stty (which is needed to adjust the TTY state for the command execution) and the invocation of starship. Each may possibly take a longer time depending on the setup.
To measure the times, could you instead run the following set of commands? Please remove your hooks in prompt_ps1_final and PREEXEC.
$ rm -f measure.txt
$ blehook POSTEXEC='bleopt debug_xtrace='
$ bleopt debug_xtrace_ps4='+[$EPOCHREALTIME $BASH_SOURCE:$LINENO${FUNCNAME:+ (${#FUNCNAME[*]} $FUNCNAME)}] '
$ ble/widget/insert-string pwd; bleopt debug_xtrace=measure.txt # <-- press [RET][RET] (i.e. twice [RET])
$ pwd <-- This will be automatically shown. You don't have to input this.
$ sed -ni.bk '\:ble-decode/\.hook 13$:,$p' measure.txtThen, can you attach the created file measure.txt?
pallaswept
ble version: 0.4.0-nightly+5676525 Bash version: 5.2.26(1)-release (x86_64-suse-linux)
I noticed a short delay whenever I ran a command. No matter what I do, I can never get it shorter than one 60Hz graphics 'frame' (~16ms). The time it takes from pressing enter, to running the command, is always the expected time, plus >16ms. It seems that the command is not executed until the display completes the update of the prompt.
I set up timestamping before and after the command, and it made this very visible:
The first time here ("...18.983ms 18/05...") is generated by ble.sh, using
bleopt prompt_ps1_final:='\e[38;5;238m\n[ `eval $NOWDATE` ]\n'The second time here ("...19.001 + 0ms...") is generated by ble.sh, usingblehook PREEXEC='bleopt exec_elapsed_mark:=$"\e[38;5;238m[ `eval $NOW` + \e[38;5;242m%s\e[38;5;238m @ \e[38;5;242m%s%%\e[38;5;238m CPU ] "'The last time here ("was 19ms") is generated by starship.Note that the command's real execution time is 0ms. But it took 19ms. Any number less than 16.7 would have been great, because to my eyes, I wait one 'frame' any way. But the delay is always (real execution time)+(~16ms). So now, even the shortest command, takes 2 whole frames, or 33.333ms, to be visible. Now that I have my timestamping working, I can see that the delay is not during the execution of the command, but before the execution of the command.
To demonstrate, the delay is not caused by the
evalcommands:Without the
timeandecho, it's 2-3ms for twoeval datecommands. So I am confident that is not the source of the delay. If I remove everything from the prompt and the pre/post-exec and all, It will always still take the 1 extra 'frame' of time.I know these are very small numbers and I worry I am being too demanding, but then, a very short command takes 3300% of the normal time, so maybe it is not such a small number after all :D I hope it might be possible to begin command execution immediately upon pressing enter, and update the prompt asynchronously? Or maybe some other method, to avoid this delay before execution?
Thanks!