fish_prompt is slow because of missed type checks

[arhag23]

fish_prompt takes roughly ~250ms to execute under current conditions.

The 'type' command used to check if something exists on the path is extremely slow on a miss. This creates a huge performance loss where it is called and a command does not exist.

Lines 1151 and 1152 seem to serve no purpose in fish_prompt.fish.

type -q bobthefish_colors
and bobthefish_colors

This check will fail since the correct function is actually __bobthefish_colors. Calling that function is also of no avail because no argument is provided and it would just set everything to the default theme instead of your selected color scheme. The correct function is already called just before and with the correct argument passed to it.

The other time this command is used is with the __bobthefish_prompt_rubies function inside fish_prompt.fish. This seems to check for a ruby installation. However, if one is not installed, there is a significant performance loss. Even if one were to require the use of this feature, a hit on the bottom level of the if/else tree would still incur significant time usage on previous misses.

Proof of time difference on using type with a command on the path vs not.

One can also see for themselves by profiling fish_prompt via fish --profile prompt.prof -c 'fish_prompt'.

A temporary fix for anyone experiencing the same issue would be to comment out the two lines in fish_prompt.fish mentioned above as well as setting theme_display_ruby to no to skip the checks for a ruby environment.

[bobthecow]

the check for bobthefish_colors is intentional. it's how you define custom color schemes.

it's really weird that yours is failing so miserably. on the two boxes I have easy access to right now, the penalty for a miss was ~1.4x (macOS, intel MBP) and ~2x (some ubuntu VM on AWS?).

[bobthecow]

Is there some other confounding factor? maybe a miss is so expensive because you're searching too many places? Is your $PATH or $fish_function_path ridiculously large? does part of either of those live on really slow disks (fuse, network mount, etc)?

[w-biggs]

Is there some other confounding factor? maybe a miss is so expensive because you're searching too many places? Is your $PATH or $fish_function_path ridiculously large? does part of either of those live on really slow disks (fuse, network mount, etc)?

Thank you, this helped me determine exactly what was happening on my end!

For anyone else having a similar issue using WSL2, like I was -- it turned out that the $PATH was the issue. By default, WSL2 appends your Windows PATH to the Linux PATH. That caused type -q bobthefish_colors to take something like 450 milliseconds for me, since /c/ is essentially a network mount, making the prompt incredibly slow. After adding the config setting mentioned here it's down to 119 microseconds.

This makes it less convenient to just call Windows executables from WSL2, but you could always add individual paths back in.