Cargo completions are very slow and block user input

[matklad]

λ fish --version
fish, version 4.0.1
λ echo $version
4.0.1

1. Type

cargo install --p

2. Press tab

3. There's about a second-long delay while the shell is completely unresponsive and doesn't accept input.

https://asciinema.org/a/paFCLfWv3pam2KEW0ImYxMydY

It looks like completion is trying to do something smart, which takes time. I am all for smart completion, but only if it is fast enough to have unnoticeable latency (Yes, the irony of rust-analyzer not being completion speed demon is not lost on me :) In my defense, fish-level of software quality was always an aspirational goal for me :P)

λ rustup --version
rustup 1.28.1 (2025-03-05)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.85.0 (4d91de4e4 2025-02-17)`
λ cargo --version
cargo 1.85.0 (d73d2caf9 2024-12-31)
λ which cargo
/Users/matklad/.cargo/bin/cargo
λ which rustup
/Users/matklad/.cargo/bin/rustup
λ uname -a
Darwin TigerMac.local 24.3.0 Darwin Kernel Version 24.3.0: Thu Jan  2 20:24:22 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6041 arm64

[faho]

Checking fish --profile /tmp/cargo.prof -c "complete -C'cargo --p'" shows as the top 8 (sort -nk2 /tmp/cargo.prof):

147956	147956	--> cargo --list 2>&1 | string replace -rf '^\s+([^\s]+)\s*(.*)' '$1\t$2' | string escape
226	148182	-> set -l __fish_cargo_subcommands (cargo --list 2>&1 | string replace -rf '^\s+([^\s]+)\s*(.*)' '$1\t$2' | string escape)
244270	244270	-----> MANPAGER=cat WHATISPAGER=cat apropos "$argv"
742	246126	----> __fish_apropos ^$argv 2>/dev/null | awk -v FS=" +- +" '{
25	246273	---> __fish_describe_command cargo-
109759	356251	--> complete -C'cargo-' | string replace -rf '^cargo-(\w+).*' '$1'
118	356369	-> set -la __fish_cargo_subcommands (complete -C'cargo-' | string replace -rf '^cargo-(\w+).*' '$1')
8713	528150	> complete -C"cargo --p"

That means it takes 528ms on my system, and most of the time is spent in complete -C"cargo-", i.e. trying to complete custom cargo subcommands (which ends up calling out to apropos, which is often dog-slow on macOS because Apple broke its cache). The second most is spent in using cargo --list's output.

This scales with $PATH - if I run this with a pruned down $PATH, it is a lot faster, even tho the directories I prune don't have any cargo- tools in them.

And the first simple fix here is to remove complete -C'cargo-' entirely, because cargo --list already includes them.

Or at least that's what a test of

printf '%s\n' '#!/bin/sh' 'echo No, car go road' > ~/.local/bin/cargo-space
chmod +x ~/.local/bin/cargo-space
cargo --list | grep space

tells me.

That'll roughly halve the time taken. Anything else would involve dropping custom cargo- tools, which seems like a shame.

[lengyijun]

cargo add xxx is slow for me too

[krobelus]

cargo install --p

My fish_trace=1 complete -C 'cargo install --p' shows it's hanging in "cargo search" for 2.5 seconds. We sometimes cache completions ("__fish_make_cache_dir") but I'm not sure if that's realistic here. Better make it async, and add a timeout for now. I think macOS has the `timeout` utility these days

[faho]

cargo search isn't the kind of thing you can really cache.

Tbh I don't know if it's a good idea to have that to begin with (it'll make a network call, which can take arbitrary time), but if we did it would probably be helpful to not do that if the current token is an option (i.e. starts with - and doesn't come after a -- separator).

[matklad]

shows it's hanging in "cargo search" for 2.5 seconds.

Confirmed the same here.

Looks like in cargo install --p we clearly know that we aren't completing crate name, so we shouldn't engage cargo search machinery at all?

And, separately from that, yeah, I'd expect to not have any networking completions at all. I'd argue that the right UX here is something like cargo add --interactive which is a (hypothetical) upstream feature which pops-up an fzf-like interface or something.

Like, it's absolutely is a real problem that you want to have some sort of completion for cargo add, but it doesn't look like shell is the right layer to solve it.

[faho]

Okay, I removed the crates.io lookup (it's usually not terribly useful because you know what to install, and it's an awkward trap to get your shell to hang) and the duplicate $PATH checking.

So now completing cargo install --p takes ~30ms instead of seconds, and completing cargo takes roughly half the time it took before (depending on $PATH).

I threw in a freebie of completing -Z options (9c5be2a), but that's not in 4.0.2.