Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bench: standalone fuzzy finder for benchmarking against other implementations #22

Closed
matu3ba opened this issue Sep 3, 2023 · 1 comment

Comments

@matu3ba
Copy link

matu3ba commented Sep 3, 2023

See jake-stewart/jfind#19 for context.

At least in the linked asciinema it is significantly slower, but I'm not sure for the exact reasons.
Startup time should be negligible for non-tiny datasets, so a fuzzer cli frontend would be easiest to use for fair comparison.

@pascalkuthe
Copy link
Member

pascalkuthe commented Sep 3, 2023

I find that comparison very odd. You are benchmarking how long it takes to stream in a file. That is limited by the file transversal which is not part of the matcher. In thus case helix is ofcourse slower because it runs the file transversal on a single thread and sorts all files.

I made that design choice deliberately since I find sorted files more important than how fast files stream in (realistically helix is not build around the idea of being opened in root). Nucleo has fully lock and wait free input so it stream in files as fast as your input stream is.

When I compared nucleo to fzf I was comparison matching speed after the stream had complemented since that is what fuzzy matchers actually do (and the stream in nucleo can never backlog).

Either way while a CLI would be nice I just don't have the time for that right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants