4 ms·

Answer: Because it is sourcing the output of `kubectl completion zsh`, which takes 130ms to execute. (The article says something about zsh “caching” a static so

Answer: Because it is sourcing the output of `kubectl completion zsh`, which takes 130ms to execute. (The article says something about zsh “caching” a static sourced file; does it actually do something like that? It still has to run the shell code, right?) Question: How the hell do you take 130ms to print out the commands to set up shell completion? Is there something meaningful happening in that time, or is this simply the cost for the kernel to load a 43 MB do-everything kubectl binary? (43 MB is a lot, admittedly, but 130ms when most of that code stays untouched still sounds high to me.)

PetitSasquatch 4y ago
I have experienced even longer with npm / Node.js autocompletion. The whole experience caused me to try different shells, I ended up on ksh for simplicity and comparative leanness, works well for my needs.
- marcthe12 4y ago
  Which ksh flavour? Also any good tutorial?
  - ratsmack 4y ago
    I have used the original ksh[1] for years, because it seem to have more features for complex shell scripts. It also supports real numbers for people that need math functions other than integer. [1] https://en.wikipedia.org/wiki/KornShell https://en.wikipedia.org/wiki/KornShell
  - PetitSasquatch 4y ago
    The ksh that ships with OpenBSD, it's available under Linux as loksh. I've never needed a tutorial as such, because found its man page to be well written and comprehensive. However, I can recommend the old book The Unix Programming Environment by Kernighan and Pike, it also is well written and helped me quite a bit. Just understanding one smaller tool (ksh) better has helped me do more with it and use fewer addons extensions, which personally make me happy; works for me.
- ilyt 4y ago
  But zsh is not slow, bloat you add to it is...
  - PetitSasquatch 4y ago
    I agree. I never found zsh inherently slow, but the reason I initially used it was to play with all the additional 'bloat' its ecosystem offered, so to speak. It was that experience which led me to look try other shells, in the end I found ksh's simpler feature set and manpage more to my liking.
vbezhenar 4y ago
Kernel does not load 43 MB. It maps file to memory and then executes it from start address. During execution, kernel paging mechanism reads parts of the file into memory as CPU touches it. So ideally this print algorithm should take few kilobytes of those 43 MB and 2-3 pages loaded from the disk. With SSD it should be significantly faster than 130 ms. What exactly happens with kubectl is hard to answer and need someone to profile it if that's true. May be it checks for updates or something like that.
oweiler 4y ago
Probably much, much faster to move the command output to a separate file and sourcing that (which requires no subshell, process substitution etc.).
- Myrmornis 4y ago
  Btw, that's precisely the conclusion of the article.
oefrha 4y ago
> The article says something about zsh “caching” a static sourced file; does it actually do something like that? It still has to run the shell code, right? No it does not, the article is wrong or phrased incorrectly. Zsh completion functions, when properly configured, are autoloaded. The function is only read from disk when called. Say with _kubectl, if you do it correctly with a static _kubectl instead of following the stupid advice of `source <(kubectl completion zsh)`, on shell startup your _kubectl should be uninitialized: $ which _kubectl _kubectl () { # undefined builtin autoload -XUz } After you actually try to complete kubectl once, run that again and this time you can see the actual function body. $ which _kubectl _kubectl () { local shellCompDirectiveError=1 # ... } That function is read from disk on use, not cached. What zsh does cache, with compinit[1], is association of commands with completion functions. compinit reads the #compdef line of functions on $fpath (e.g. `#compdef _kubectl kubectl`), and generates a ~/.zcompdump (or some other path, mine is ~/.local/share/zsh/compdump for instance), which is basically a list of command and completion function pairs, plus a huge autoload invocation registering all the completion functions. This way zsh knows which function to load when a command needs completion. [1] https://zsh.sourceforge.io/Doc/Release/Completion-System.html#Use-of-compinit https://zsh.sourceforge.io/Doc/Release/Completion-System.htm...
jrockway 4y ago
It seems odd to run kubectl every time you open the shell. I just save the output and source it in every shell. On my machine it's 40ms to create a shell and eval the output of "kubectl completion bash". It's <10ms to "source ~/.dotfiles/compleation/kubectl".
deleted 4y ago
[deleted]

PetitSasquatch 4y ago

I have experienced even longer with npm / Node.js autocompletion. The whole experience caused me to try different shells, I ended up on ksh for simplicity and comparative leanness, works well for my needs.

marcthe12 4y ago
Which ksh flavour? Also any good tutorial?
- ratsmack 4y ago
  I have used the original ksh[1] for years, because it seem to have more features for complex shell scripts. It also supports real numbers for people that need math functions other than integer. [1] https://en.wikipedia.org/wiki/KornShell https://en.wikipedia.org/wiki/KornShell
- PetitSasquatch 4y ago
  The ksh that ships with OpenBSD, it's available under Linux as loksh. I've never needed a tutorial as such, because found its man page to be well written and comprehensive. However, I can recommend the old book The Unix Programming Environment by Kernighan and Pike, it also is well written and helped me quite a bit. Just understanding one smaller tool (ksh) better has helped me do more with it and use fewer addons extensions, which personally make me happy; works for me.
ilyt 4y ago
But zsh is not slow, bloat you add to it is...
- PetitSasquatch 4y ago
  I agree. I never found zsh inherently slow, but the reason I initially used it was to play with all the additional 'bloat' its ecosystem offered, so to speak. It was that experience which led me to look try other shells, in the end I found ksh's simpler feature set and manpage more to my liking.

vbezhenar 4y ago

Kernel does not load 43 MB. It maps file to memory and then executes it from start address. During execution, kernel paging mechanism reads parts of the file into memory as CPU touches it. So ideally this print algorithm should take few kilobytes of those 43 MB and 2-3 pages loaded from the disk. With SSD it should be significantly faster than 130 ms. What exactly happens with kubectl is hard to answer and need someone to profile it if that's true. May be it checks for updates or something like that.

oweiler 4y ago

Probably much, much faster to move the command output to a separate file and sourcing that (which requires no subshell, process substitution etc.).

Myrmornis 4y ago
Btw, that's precisely the conclusion of the article.

oefrha 4y ago

> The article says something about zsh “caching” a static sourced file; does it actually do something like that? It still has to run the shell code, right? No it does not, the article is wrong or phrased incorrectly. Zsh completion functions, when properly configured, are autoloaded. The function is only read from disk when called. Say with _kubectl, if you do it correctly with a static _kubectl instead of following the stupid advice of `source <(kubectl completion zsh)`, on shell startup your _kubectl should be uninitialized: $ which _kubectl _kubectl () { # undefined builtin autoload -XUz } After you actually try to complete kubectl once, run that again and this time you can see the actual function body. $ which _kubectl _kubectl () { local shellCompDirectiveError=1 # ... } That function is read from disk on use, not cached. What zsh does cache, with compinit[1], is association of commands with completion functions. compinit reads the #compdef line of functions on $fpath (e.g. `#compdef _kubectl kubectl`), and generates a ~/.zcompdump (or some other path, mine is ~/.local/share/zsh/compdump for instance), which is basically a list of command and completion function pairs, plus a huge autoload invocation registering all the completion functions. This way zsh knows which function to load when a command needs completion. [1] https://zsh.sourceforge.io/Doc/Release/Completion-System.html#Use-of-compinit https://zsh.sourceforge.io/Doc/Release/Completion-System.htm...

jrockway 4y ago

It seems odd to run kubectl every time you open the shell. I just save the output and source it in every shell. On my machine it's 40ms to create a shell and eval the output of "kubectl completion bash". It's <10ms to "source ~/.dotfiles/compleation/kubectl".

deleted 4y ago

[deleted]