Slow startup over SSH with `--height`

[pdf]

• Category
  • [x] fzf binary
  • [ ] fzf-tmux script
  • [ ] Key bindings
  • [ ] Completion
  • [ ] Vim
  • [ ] Neovim
  • [ ] Etc.
• OS
  • [x] Linux
  • [ ] Mac OS X
  • [ ] Windows
  • [ ] Windows Subsystem for Linux
  • [ ] Etc.
• Shell
  • [x] bash
  • [x] zsh
  • [ ] fish

When starting fzf with --height > 0 on a remote host connected via SSH startup is very slow, resulting in dropped keystroke input. Locally, or inside a remote tmux session on the same connection, startup time is fast as expected. I tested in both zsh and bash, both exhibit the same behaviour.

I'd guess it's something to do with how the terminal size is computed, let me know if there's anything I can do to help debug.

[junegunn]

I just tested the option on 6 different remote servers over ssh, but I was unable to reproduce the issue. Do you have the same issue when you connect to localhost via ssh?

[pdf]

Do you have the same issue when you connect to localhost via ssh?

Hrm, not noticably, so the delay appears to be largely exacerbated by latency. I use hosts at long distance regularly, the delay might be some multiple of the RTT.

Interestingly, I can get lines/cols from the shell immediately on the same systems that produce the problem with fzf (and fzf starts at normal speed inside tmux):

time tput lines
58
tput lines  0.00s user 0.00s system 0% cpu 0.001 total

[alok]

I have a related issue with --height where fzf is has a lag when starting with it set but is instant if I remove it. I have no idea why, but it sounds somewhat related to this.

[danudey]

I've been encountering this issue since my team started working from home, and I couldn't figure it out. Thanks to @pdf and this ticket, and @alok for his comment, I've managed to figure out the following:

• I get this ~1 second delay on my work desktop via SSH, even though I've never had running it locally on that system
• I only get it if I use --height, whether with a percentage or fixed size
• It happens every time for me (and here's an asciinema: https://asciinema.org/a/Sef9PYs0cxGE9dVHsxjgFVsjU)
• It only happens if I SSH from Windows
• It happens if I open a cmd.exe window, or if I use the new Windows Terminal to launch Powershell, and then SSH from there
• It doesn't happen if I use the new Windows Terminal to launch an Ubuntu 18.04 WSL session and SSL from there
• It doesn't happen if I launch a cmd.exe window or a Powershell tab, then use that window to launch Ubuntu 18.04 WSL (via ubuntu1804.exe), and then SSH

At this point, the only thing I could think of that could be the singular link is the specific Windows SSH client/version/build/etc. Perhaps it's passing wrong, slow, or broken values to the remote end?

Perhaps this will make it possible to reproduce. If you need more data, please let me know, as I'm incredibly eager to see this resolved.