Homebrew install makes kubectx slow

[edgan]

If I run brew install kubectx and then run time kubectx it takes 3+ seconds. Digging into the why I found that the copy of kubectx seems to be a bash script that calls kubectl instead of the native binary version of kubectx. When trying to use shell completion it is painfully slow.

Arch:

arm64

OS version:

MacOS 13.4

Version:

0.9.5

Expected:

kubectx  0.00s user 0.00s system 82% cpu 0.002 total

Actual:

kubectx  0.13s user 0.07s system 5% cpu 3.856 total

[edgan]

Bash - slow: https://github.com/ahmetb/kubectx/releases/download/v0.9.5/kubectx

Native binary - fast: https://github.com/ahmetb/kubectx/releases/download/v0.9.5/kubectx_v0.9.5_darwin_arm64.tar.gz

[ahmetb]

Before we go into Bash vs Go implementations, I assume you use the bash script-based implementation?

Does "kubectl config list-contexts" also take 3s?

If that's the case let's try to figure out why, as it'll impact your shell completion time regardless of kubectx implementation.

[edgan]

I couldn't find kubectl config list-contexts, but did find kubectl config get-contexts. kubectl config get-contexts was slow. I found I was using kubectl from rancher-desktop. When I moved rancher-desktop's bin directory from the beginning of the PATH to the end up the PATH it became fast. The reason is that I was then using kubectl from brew.

Update: Upgrading rancher-desktop helped by 100%, but its kubectl is still between 280% slower and 600% slower.

[ahmetb]

Kubectl shouldn't take a second to list contexts. Feel free to add -v=10 flag to see where the time is spent. Regardless, it doesn't seem the issue is with this tool.

If it turns out kubectl is unnecessarily slow, you can file an issue in kubectl repo. It might be a regression.

[edgan]

@ahmetb My question is why have a bash version and a native binary version? I could make arguments for both, but having both seems redundant.

[ahmetb]

@edgan this is not really the place to debate that :) many distros still package and distribute the shell version.

Go version works on Windows, and has some other benefits like it can preserve kubeconfig file structure/comments while changing contexts. But it has some poor handling around multiple KUBECONFIGs joined (:) and auth providers that write back to kubeconfig file after authentication.

So for some users the shell has the most backwards compatibility as it shells out to kubectl. Whereas most users are probably fine with Go implementation.