Prompt much slower in Fish in Warp

[ctbeiser]

Discord username (optional)

No response

Describe the bug

If I open a bash shell in Warp, it's about as fast as in Terminal.

However, if I use Fish, things get much slower. For example, pressing return in a small directory with a git repo takes 0.2s in Warp, but is ~instant in Terminal or with Bash.

If I go somewhere without a git repo, it takes 0.02s—much better.

My guess is that there's a holdup that affects my prompt, which gets git info from the local directory.

To Reproduce

• Install fish
• Set prompt to "compact git"
• enter a git repo
• press return

Expected behaviour

prompt shows ~instantly

Screenshots

Operating System

MacOS

OS Version

12.3

Additional context

fish version 3.3.1

[warpdotdev-dx]

Thanks for the feedback! This is unusual, it's like something in the dotfiles that's slowing it down in relation to Warp. Could you disable some of the components in your dotfiles just for Warp and try to isolate what specifically is slowing it down? We have instructions here: https://docs.warp.dev/help/known-issues#configuring-and-debugging-your-rc-files​ The fish equivalent should be something like this however: ``` if test "$TERM_PROGRAM" != "WarpTerminal" # Stuff here end ```

[ctbeiser]

Here's what I've found:

If I run fish_config prompt choose informative_vcs, and I'm in a git repo, then I get the slowdown.

Meanwhile, fish_config prompt choose informative is perfectly fast.

Other than that, my fish install is basically out of the box, so I would expect that should be enough to reproduce.

[warpdotdev-dx]

Thanks for sharing this!

[elviskahoro]

One of our engineers looked into this and we believe the slowdown is due to fish querying the Git status, which will naturally take longer than not doing so. However we actually don't think the slow down is anything we're doing—nor does it seem like it's significantly slower in Terminal.app or iTerm.

It probably looks much worse in Warp though cause of this bug:

• Window content jumps down than back up after every command / flickering / stuttering #743

[ctbeiser]

Looking more closely, I think you may be right—the thing I'm noticing is that "time until I can read the output of the command" is much higher, because I can't until it stops moving. Happy to close this.