Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


There'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.


Thanks for pointing this out. I guess fzy's primary goal is path matching which might explain this behaviour.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: