You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: