Closed GopherJ closed 2 months ago
fzy is faster than skim, skim is faster than fzf
Nope. https://github.com/lotabout/skim/issues/317
And even that was when fzf was much slower than it is now.
@junegunn do you have a guess on why my fzf starts to be super slow recently? I use the following command and it's super slow in a 50k lines rust repo
fd --type f --exclude .git --exclude node_modules --exclude .cache --exclude third-party --exclude vendor --exclude target --exclude Cargo.lock --exclude yarn.lock --exclude package-lock.json --exclude .zig-cache --follow --hidden
for example you can use https://github.com/0xPolygonZero/plonky2 repo
in this example, fzf is noticeable twice slow than skim, much slower than fzy. To be more specific, fzf took ~2s, skim took ~1s, fzy is instant
Please provide the exact steps to reproduce the problem you're experiencing. What version did you use? What command did you use on what environment? What exactly was slow, loading of the list, or filtering of the list? What query pattern did you use? A screen recording of the situation would be helpful.
The plonky2 repository only has 290 files, and I don't think any of the programs will show any noticeable delay in processing such a tiny list.
@junegunn the latest version of fzf and loading the list have been slow, all I'm saying is running:
fzf
directly, no query pattern, it took around 2seconds I'm not sure what happened. If you have time you can try to run:
fzf => 2s
sk => 1s
find . -type f | fzy => instant
How about find . -type f | fzf
? Do you have $FZF_DEFAULT_COMMAND
set?
@junegunn hi, I have FZF_DEFAULT_COMMAND
@junegunn do you have a guess on why my fzf starts to be super slow recently? I use the following command and it's super slow in a 50k lines rust repo
fd --type f --exclude .git --exclude node_modules --exclude .cache --exclude third-party --exclude vendor --exclude target --exclude Cargo.lock --exclude yarn.lock --exclude package-lock.json --exclude .zig-cache --follow --hidden
for example you can use https://github.com/0xPolygonZero/plonky2 repo
in this example, fzf is noticeable twice slow than skim, much slower than fzy. To be more specific, fzf took ~2s, skim took ~1s, fzy is instant
@junegunn I observed a wierd thing, I reinstalled fzf from apt and it turns out to be much faster than before, not sure what happened on the installation process
a week or so I did an update using vim-plug, then fzf becomes noticeable slow
How about
find . -type f | fzf
?
@junegunn
find . -type f | fzf
do you have a way to benchmark? After reinstalling, sk and fzf perform quite similar in a 60k codebase, but fzf took longer to scan larger dataset (124GB)
My current fzf version is:
0.29 (devel)
My current sk version is:
sk 0.10.4
when I say it took longer I mean find . -type f | fzf
vs find . -type f | sk
, if we run them directly it's not noticeable
I tried also telescope + fzf native and they are really fast but they have bugs. wondering if fzf.nvim can support more fuzzer so that people can switch.
As the codebase going bigger I think people will prefer native c version backend
fzf => 2s sk => 1s find . -type f | fzy => instant
I was referring to this. You said fzy is fastest and sk is faster based on this observation. So I asked you how find . -type f | fzf
works. Is it instant, or is it still 2 seconds? Because you said you have $FZF_DEFAULT_COMMAND
, if it's instant,
it hints that there's something wrong with your shell configuration, and you'll likely experience the same amount of delay when you do time $SHELL -c "$FZF_DEFAULT_COMMAND" > /dev/null
, and it has nothing to do with fzf's performance.
0.29 (devel)
That's extremely outdated. The current version is 0.54.1.
hi @junegunn sorry I was quite busy and didn't get time to reply, I think you can forget this issue for now. after reinstall + switching versions etc. It works quite fast now.
So I think we just keep what it is should be good. Telescope has more bugs than fzf, I love the stability you provide, thanks for your hard work!
man fzf
)