I have been really inspired by 'fzf' recently. Wrote a fun little ZFS utility[0] which I intended to just script with 'fzf', but have since found skim[1], or 'sk', and now use it both as my sole fuzzy finder app (because it's supposed to be interactive and it's faster!), and as a library for my little utility.
I like them both for making fun zsh key bindings, so, so easy.
That's a good question. I'd be interested in any benchmark you saw. And although it seems like sk has come a long way since 2020[0], it may still be slower reading in a larger file. I really don't know.
But I suppose I'd ask -- faster how?
The linked benchmark really doesn't mean much to me. As an interactive app I judged it on how it felt latency-wise at the CLI. So, I would just try to scroll page-up while find was feeding in the files in my home directory. fzf would sometimes stall on my system (again not scientific) and would occasionally junk up the terminal when it got fed something strange. This could be a problem with fzf or it could have been a problem with how I was using it.
On the other hand, sk at the CLI has been rock solid and very fast. skim as a library needs better docs and has a few other teething issues, but I'm using skim right now, because it feels faster, and because I use it as a library, there is some mental continuity between the two. Recognize and respect fzf in this space, it's just sk is doing it better for me, for now.
Skim is effectively dead. fzf continues to receive new features and improvements. One of the stated goals of skim is that it will be option-compatible with fzf.
Unfortunately that's only superficially true at this point. I recently removed sk support from a project because I was tired of special-casing for it. (ZFSBootMenu).
I like them both for making fun zsh key bindings, so, so easy.
[0]: https://github.com/kimono-koans/httm [1]: https://github.com/lotabout/skim