You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The first thing I did after recently installing this wonderful for the first time, was to, of course, enable some stuff. bash-it show was what I used for this of course, since I wasn't aware of all the things available and their roles. After getting a bit used to it though, I didn't need to have everything printed on my screen, but I preferred to get a little help about what's there from my beloved completions. Since I installed Bash-it on other machines too, I used the enable action more than anything else, and that's how I noticed that getting completions for it is from slow to painfully slow. On my laptop, surprisingly to me, it wasn't that slow, it would take 0.5-1.5s to show suggestions. On my phone, using termux, it takes about 4-4.5s, and on my gcp server it also is rather slow, though it's much more powerful than my laptop.
Possible Solution
So I decided to go on and try to debug it. I set the xtrace option and watched what takes so long when bash-it completions are generated. I noticed that the longest portion of time is spent on iterating through each and every file under ${BASH_IT}/$subdirectory/ and ${BASH_IT}/enabled/}. There also was a bit of excessive external programs invocation, instead of shell builtins, but this wasn't really the issue here, although I thought it could be before I debugged it. The for loops used there didn't seem that performant indeed, but I would expect them to run fast nevertheless (there aren't so many files any way). I'm still a bit unsure about why this is so slow, I don't know if it's a specific point in the loop, of just the logic of iterating here isn't suitable overall. Also, this is most noticable with enable, since it has to process the most files and has the longest loop, but if measured the rest of the options with time, a delay will be noticed there too.
So the solution is obvious. There shouldn't be iteration through the files, but do the same thing in batch. I came up with a solution, which worked pretty well, so I'll open a PR with it.
The first thing I did after recently installing this wonderful for the first time, was to, of course, enable some stuff.
bash-it show
was what I used for this of course, since I wasn't aware of all the things available and their roles. After getting a bit used to it though, I didn't need to have everything printed on my screen, but I preferred to get a little help about what's there from my beloved completions. Since I installed Bash-it on other machines too, I used theenable
action more than anything else, and that's how I noticed that getting completions for it is from slow to painfully slow. On my laptop, surprisingly to me, it wasn't that slow, it would take 0.5-1.5s to show suggestions. On my phone, using termux, it takes about 4-4.5s, and on my gcp server it also is rather slow, though it's much more powerful than my laptop.Possible Solution
So I decided to go on and try to debug it. I set the
xtrace
option and watched what takes so long when bash-it completions are generated. I noticed that the longest portion of time is spent on iterating through each and every file under${BASH_IT}/$subdirectory/
and${BASH_IT}/enabled/}
. There also was a bit of excessive external programs invocation, instead of shell builtins, but this wasn't really the issue here, although I thought it could be before I debugged it. Thefor
loops used there didn't seem that performant indeed, but I would expect them to run fast nevertheless (there aren't so many files any way). I'm still a bit unsure about why this is so slow, I don't know if it's a specific point in the loop, of just the logic of iterating here isn't suitable overall. Also, this is most noticable withenable
, since it has to process the most files and has the longest loop, but if measured the rest of the options withtime
, a delay will be noticed there too.So the solution is obvious. There shouldn't be iteration through the files, but do the same thing in batch. I came up with a solution, which worked pretty well, so I'll open a PR with it.
Your Environment
HEAD
bash-it doctor
output:WARN: core: main: BASH_IT_THEME variable not initialized, please upgrade your bash-it version and reinstall it!
DEBUG: core: main: Loading libraries(except appearance)...
DEBUG: lib: helpers: Loading library file...
DEBUG: lib: log: Loading library file...
DEBUG: lib: preview: Loading library file...
DEBUG: lib: search: Loading library file...
DEBUG: lib: utilities: Loading library file...
DEBUG: vendor: Loading "preexec"...
DEBUG: core: reloader: Loading all enabled components...
DEBUG: aliases: general: Loading component...
WARN: aliases: general: Command 'gshuf' does not exist!
DEBUG: plugin: base: Loading component...
WARN: plugin: base: Command 'markdown' does not exist!
WARN: plugin: base: Command 'mkisofs' does not exist!
DEBUG: plugin: edit-mode-vi: Loading component...
DEBUG: plugin: history-search: Loading component...
DEBUG: plugin: history: Loading component...
DEBUG: plugin: man: Loading component...
DEBUG: plugin: zoxide: Loading component...
DEBUG: completion: bash-it: Loading component...
DEBUG: completion: pip: Loading component...
DEBUG: completion: pip3: Loading component...
DEBUG: completion: pipenv: Loading component...
WARN: completion: pipenv: Command 'pipenv' does not exist!
DEBUG: completion: system: Loading component...
WARN: completion: system: Binary 'brew' does not exist!
DEBUG: plugin: alias-completion: Loading component...
DEBUG: core: main: Loading custom aliases, completion, plugins...
DEBUG: core: main: Loading general custom files...
DEBUG: custom: example: Loading custom file...
WARN: custom: example: Command 'reload' does not exist!
The text was updated successfully, but these errors were encountered: