5 ms·
fzy[1], which is written in C, seems to be slightly faster: $ hyperfine --warmup 2 -r 10 'rg --files | fzy -e hello' 'rg --files | fzf -f hello' Bench
by hwj 7y ago
fzy[1], which is written in C, seems to be slightly faster:
$ hyperfine --warmup 2 -r 10 'rg --files | fzy -e hello' 'rg --files | fzf -f hello'
Benchmark #1: rg --files | fzy -e hello
Time (mean ± σ): 153.6 ms ± 57.9 ms [User: 399.2 ms, System: 96.9 ms]
Range (min … max): 85.9 ms … 244.3 ms 10 runs
Benchmark #2: rg --files | fzf -f hello
Time (mean ± σ): 210.5 ms ± 61.6 ms [User: 443.3 ms, System: 90.9 ms]
Range (min … max): 123.3 ms … 315.5 ms 10 runs
Summary
'rg --files | fzy -e hello' ran
1.37 ± 0.65 times faster than 'rg --files | fzf -f hello'
[1] https://github.com/jhawthorn/fzy https://github.com/jhawthorn/fzy
- yaantc 7y agoThere's a big difference in how their matching works, that made me prefer fzf. It's related to how they deal with spaces. With fzf, and also helm in Emacs, rofi... a space is a separator between matchers, and the order of the matchers does not matter. So if you type "foo bar", it will select a path "/bar/bla/foo" just fine. This is important to me for discoverability: very often you know quite well what keywords to look for, but you don't know or are not sure about the order. So order irrelevance is very important. fzy treats the space as a literal. So the order matters. And that's a killer for me. Plus in my experience the speed difference is not important, all are fast enough in practice.
- hwj 7y agoThanks for pointing this out. I guess fzy's primary goal is path matching which might explain this behaviour.