fzf becomes laggy, around 0.5 second before content is shown

[amosbird]

• 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
  
  
  
  • [ ] bash
  
  
  • [ ] zsh
  
  
  • [x] fish
  
  

I'm using the latest fzf with zero option. It used to be instant. What should I do?

[junegunn]

Which version did you have previously?

[amosbird]

1ba7acf4bd4314f299b57cea73cbd376bde5aba3

[junegunn]

I currently have no idea what might have caused the issue you experience. It would be helpful if you could pinpoint the exact version that started showing the symptom.

https://github.com/junegunn/fzf-bin/releases

[amosbird]

well, I just tested a bunch of releases and found that this isn't a regression. fzf performs instantly in my Archlinux but is noticable slow in centos 7.

[junegunn]

Strange, I have tested fzf on Centos 7 from time to time but I haven't experienced the problem.

[rstacruz]

I'm experiencing the same problem. I'm on OSX uing the fish shell, if that makes any difference.

[rstacruz]

• 0.16.7 is the last official version that's not laggy for me.
• 0.16.8 starts to be laggy.
• f4731c051 is the first master commit that makes it laggy.

[junegunn]

Do you have the same issue on bash and zsh?

[rstacruz]

yes, same with bash. I'm investigating a bit further.

• OSX
• Neovim 0.1.7
• Tmux
• iTerm2

[rstacruz]

Digging further:

• 8aab0fc1894facf9ac51132ff8a832b18bc115ac is laggy
• 21d664d670182a7937f3fc783cac11fa1c2afab4 (its parent commit) is not

[junegunn]

A quick check: is echo foo | fzf laggy?

[rstacruz]

nope, the bin is just fine. It's the (neo)vim plugin.

[rstacruz]

Okay, I'm upgrading to neovim 0.2.0 and seeing if this persists.

[junegunn]

What's your &shell on nvim?

[rstacruz]

tried with both /usr/local/bin/fish and /bin/bash and both yield the same result.

btw, using g:fzf_prefer_tmux=1 is less laggy.

[rstacruz]

Okay, neovim 0.2.0 fixes it :-)

[junegunn]

Good to hear, thanks. It's hard for me to see how 8aab0fc1894facf9ac51132ff8a832b18bc115ac made things slower for older neovim though.

[rstacruz]

same! i'm completely stumped as :echomsg fzf#shellescape('hello') is not laggy at all...

[rstacruz]

how about showing a warning for those using nvim < 0.2.0?

[amosbird]

well, this is really slow now https://la.wentropy.com/E7zr.webm and it happens in both arch and centos 7

[junegunn]

@amosbird What's your $SHELL? Do you see the same delay when you do eval "$SHELL -c 'echo foo'"?

[amosbird]

shell is /usr/local/bin/fish. ah, yeah, I observe the same latency when doing eval "$SHELL -c 'echo foo'". Nice catch! How can I use bash to eval fzf?

[junegunn]

Well, the best thing you can do is to make fish start faster. I don't know much about fish, but for bash and zsh, they start pretty quickly when a command is given, because they don't have to set up things for interactive session.

> time bash -c 'echo foo'
foo

real    0m0.005s
user    0m0.001s
sys     0m0.002s
> time bash -ci 'echo foo'
foo

real    0m0.085s
user    0m0.052s
sys     0m0.025s

So I think, ideally, fish should also start faster when given a command.

If it's simply not possible to make fish start any faster you can consider globally setting SHELL to /bin/sh or /bin/bash in your configuration file. Defining an alias or function can be another option. I would do alias fzf='SHELL=/bin/sh fzf' on bash or zsh, but I don't know how to do the same on fish.

[amosbird]

I've made

 ENV ❯ time $SHELL -c 'echo foo'
foo
0.02user 0.00system 0:00.02elapsed 100%CPU (0avgtext+0avgdata 3300maxresident)k
0inputs+0outputs (0major+1093minor)pagefaults 0swaps

 ENV ❯ time $SHELL -i -c 'echo foo'
foo
0.04user 0.01system 0:00.05elapsed 111%CPU (0avgtext+0avgdata 3356maxresident)k
0inputs+8outputs (0major+3658minor)pagefaults 0swaps

However fzf-tmux is still a bit slow ...

[junegunn]

Does tmux split-window 'bash -c "echo foo"' finish quickly? fzf-tmux explicitly uses bash.

Personally, I no longer use fzf-tmux, most of the time, I use --height option instead.

[amosbird]

hmm, tmux split-window 'fzf' is fast while fzf-tmux is kinda laggy. And fzf --height doesn't restore the shell's origninal position.

[junegunn]

Can you try profiling the script? e.g. https://stackoverflow.com/questions/5014823/how-to-profile-a-bash-shell-script-slow-startup

[amosbird]

++ 1498108153.967040298  command -v fzf
+ 1498108153.970302610   fzf=/home/amos/.fzf/bin/fzf
+ 1498108153.972514233   [[ -x /home/amos/.fzf/bin/fzf ]]
+ 1498108153.974570908   args=()
+ 1498108153.976632577   opt=
+ 1498108153.978723476   skip=
+ 1498108153.980687586   swap=
+ 1498108153.982569024   close=
+ 1498108153.984684553   term=
+ 1498108153.986975828   [[ -n '' ]]
++ 1498108153.989675108  tput lines
+ 1498108153.993719334   lines=24
+ 1498108153.995732348   [[ -n '' ]]
++ 1498108153.998312386  tput cols
+ 1498108154.002055352   columns=80
+ 1498108154.004259812   [[ 0 -gt 0 ]]
+ 1498108154.006043140   [[ -z /tmp/tmux-1000/default,40926,0 ]]
+ 1498108154.007755552   [[ '' =~ ^-h ]]
+ 1498108154.009516125   [[ ! '' =~ ^-h ]]
+ 1498108154.011226253   [[ 24 -le 15 ]]
+ 1498108154.012965354   args+=("--no-height")
+ 1498108154.015285320   tmux list-panes -F '#F'
+ 1498108154.015677033   grep -q Z
+ 1498108154.021037130   set -e
+ 1498108154.022793709   id=293
+ 1498108154.024553379   argsf=/tmp/fzf-args-293
+ 1498108154.026238370   fifo1=/tmp/fzf-fifo1-293
+ 1498108154.027939803   fifo2=/tmp/fzf-fifo2-293
+ 1498108154.029652577   fifo3=/tmp/fzf-fifo3-293
+ 1498108154.031380443   trap 'cleanup 1' SIGUSR1
+ 1498108154.032898761   trap cleanup EXIT
+ 1498108154.034439007   envs='env TERM=xterm-tmux-256color '
+ 1498108154.035978555   [[ -n --ansi --multi --bind=ctrl-v:half-page-down,alt-v:half-page-up,ctrl-l:accept ]]
++ 1498108154.038234806  printf %q '--ansi --multi --bind=ctrl-v:half-page-down,alt-v:half-page-up,ctrl-l:accept'
+ 1498108154.040512114   envs='env TERM=xterm-tmux-256color  FZF_DEFAULT_OPTS=--ansi\ --multi\ --bind=ctrl-v:half-page-down\,alt-v:half-page-up\,ctrl-l:accept'
+ 1498108154.042079500   [[ -n '' ]]
+ 1498108154.043619396   mkfifo -m o+w /tmp/fzf-fifo2-293
+ 1498108154.046794332   mkfifo -m o+w /tmp/fzf-fifo3-293
+ 1498108154.049732166   opts=
+ 1498108154.051317807   for arg in '"${args[@]}"'
+ 1498108154.052889030   arg=--no-height
+ 1498108154.054419906   arg=--no-height
+ 1498108154.055938084   arg=--no-height
+ 1498108154.057462828   arg=--no-height
+ 1498108154.058962316   opts=' "--no-height"'
+ 1498108154.060521354   pppid=1669
+ 1498108154.062074580   trap_set='trap '\''kill -SIGUSR1 -1669'\'' EXIT SIGINT SIGTERM'
+ 1498108154.063623998   trap_unset='trap - EXIT SIGINT SIGTERM'
+ 1498108154.065283621   [[ -n '' ]]
+ 1498108154.066832070   [[ -t 0 ]]
+ 1498108154.068349555   cat
++ 1498108154.072782965  printf %q /home/amos
++ 1498108154.076515504  echo /tmp/tmux-1000/default,40926,0
++ 1498108154.076606524  cut -d , -f 1,2
+ 1498108154.080100831   TMUX=/tmp/tmux-1000/default,40926
+ 1498108154.081769037   tmux set-window-option synchronize-panes off ';' set-window-option remain-on-exit off ';' split-window 'trap '\''kill -SIGUSR1 -1669'\'' EXIT SIGINT SIGTERM;cd /home/amos;env TERM=xterm-tmux-256color  FZF_DEFAULT_OPTS=--ansi\ --multi\ --bind=ctrl-v:half-page-down\,alt-v:half-page-up\,ctrl-l:accept bash /tmp/fzf-args-293;trap - EXIT SIGINT SIGTERM'
+ 1498108154.114108411   cat /tmp/fzf-fifo2-293
++ 1498108155.066716100  cat /tmp/fzf-fifo3-293
+ 1498108155.070394218   exit 130
+ 1498108155.072754943   cleanup
+ 1498108155.075159843   rm -f /tmp/fzf-args-293 /tmp/fzf-fifo1-293 /tmp/fzf-fifo2-293 /tmp/fzf-fifo3-293
+ 1498108155.078853346   [[ -n '' ]]
+ 1498108155.081369417   '[' 0 -gt 0 ']'
+ 1498108155.083974041   set +x

[junegunn]

Thanks, but nothing looks too out of the ordinary as far as I can see. There are just too many commands involved, unfortunately. Let me know if you have ideas to make the routine more efficient.

[robvolk]

I had a similar lag when calling :Files using a key mapping and just figured out why. It would lag about half a second after hitting the keys before showing the fuzzy finder. Turns out I had two similar key mappings, and vim was waiting to see if I hit the second key or not.

" .vimrc
nmap <silent> <leader>t :Files<CR>
nmap <silent> <leader>tt :call (something else)<CR>

Changing the tt to something else fixed the issue! Makes sense in hindsight.