It has never been ripgrep for decades for those of us on IDEs.
However, it's coming up on a decade (8 years) of vscode using ripgrep behind the scenes.
The future of code search is not regex – 100x faster than ripgrep
21–30 of 46 posts
Re: The future of code search is not regex – 100x faster than ripgrep
#22I've entered "bazel" and got `shellPrefix.ts` which doesn't relate to bazel in any way.
If that's the future then I'll stay in the past with ripgrep.
Re: The future of code search is not regex – 100x faster than ripgrep
#23Re: The future of code search is not regex – 100x faster than ripgrep
#24It has never been ripgrep for decades for those of us on IDEs.
However, it's coming up on a decade (8 years) of vscode using ripgrep behind the scenes.
A programmer's editor. However with the right plugins, you get the same IDE capabilities for code searching in Java, C#, C++,...
Which basically runs an IDE headless (Eclipse, Netbeans, VS services,...), the joy of running an IDE + Electron, get to put those cores to use.
Re: The future of code search is not regex – 100x faster than ripgrep
#25considering 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 crate says it uses SIMD, but the crate also says that content search is 20-50 times faster. Maybe the guy unsure how fast it is or how much speedup he should claim to get recognition.
Re: The future of code search is not regex – 100x faster than ripgrep
#26[flagged]
Re: The future of code search is not regex – 100x faster than ripgrep
#27It has never been ripgrep for decades for those of us on IDEs.
To be fair, ripgrep is approximately one decade old, would be tricky to have used it for decades.
Re: The future of code search is not regex – 100x faster than ripgrep
#28Where can I find the benchmark for the "20-50 times faster than ripgrep" claim from the documentation, or the "100x faster" claim from the HN submission title?
Ripgrep already has optimizations for regex which don't contain any patterns (or even just regex which contain such substrings). So "not regex" shouldn't be what makes the difference.
Re: The future of code search is not regex – 100x faster than ripgrep
#29I've entered "bazel" and got `shellPrefix.ts` which doesn't relate to bazel in any way. If that's the future then I'll stay in the past with ripgrep.
It's O(1) with a correctness of O(0)