The future of code search is not regex – 100x faster than ripgrep
fff.dmtrkovalenko.dev
The future of code search is not regex – 100x faster than ripgrep
1–10 of 46 posts
Re: The future of code search is not regex – 100x faster than ripgrep
#2I have open sourced the fastest code search implementation. Comprehensive SDK for both file finder and grep file search that is over 100x faster than ripgrep
Re: The future of code search is not regex – 100x faster than ripgrep
#3I have open sourced the fastest code search implementation. Comprehensive SDK for both file finder and grep file search that is over 100x faster than ripgrep
This looks cool!
You should add a link to the GitHub repo for the project itself, at first I wasn't even sure what it was called.
I found this link https://github.com/dmtrKovalenko/fff.nvim
Re: The future of code search is not regex – 100x faster than ripgrep
#4I ran across this fascinating tool a few days ago researching embedding models on hugging face.
Advertised as "ColGREP Semantic code search for your terminal and your coding agents",
I haven't put it in any harness yet but I probably should.
https://github.com/lightonai/next-plaid/tree/main/colgrep
I've also tried astgrep (also known as sg) but llms really mess up on them. I think you'd need to fine tune.
If anyone has cracked that case I'd love to hear about it
Re: The future of code search is not regex – 100x faster than ripgrep
#5How's it work? Embed tokens and use euclidean distance or something?
Re: The future of code search is not regex – 100x faster than ripgrep
#6I have open sourced the fastest code search implementation. Comprehensive SDK for both file finder and grep file search that is over 100x faster than ripgrep
I don't get this submission title. Your tool uses regex but the title claims the future is not about regex.
Re: The future of code search is not regex – 100x faster than ripgrep
#7Why is it "for neovim"? Surely such a thing would be useful in many applications?
Re: The future of code search is not regex – 100x faster than ripgrep
#8considering that ripgrep has marginal overhead over just reading the files to /dev/null, how exactly does this achieve 100x speedup?
I have a lot of use for something that can search ~1GB of text "instantly", but so far nothing beats rg/ag after the data has been moved into RAM.
Re: The future of code search is not regex – 100x faster than ripgrep
#9considering that ripgrep has marginal overhead over just reading the files to /dev/null, how exactly does this achieve 100x speedup? I have a lot of use for something that can search ~1GB of text "instantly", but so far nothing beats rg/ag after the data has been moved into RAM.
The trick to optimization is not "doing faster" but "doing less". I already feel rg is missing a ton of results I want to see because it has a very large ignore list by default.
Re: The future of code search is not regex – 100x faster than ripgrep
#10Why is it "for neovim"? Surely such a thing would be useful in many applications?
Because it's being dishonest from multiple angles.
- it has regex, so the title is weird - it definitely wouldn't be 100x faster than rg - its an sdk, so its apples to oranges anyway