considering 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.
you can try it yourself. ripgrep search for "MAX_FILE_SIZE" in the chromium repo takes 6-7 seconds, with fff it is 20milliseconds
so essentially in this specific case it is over 1000x faster, but the repo size is huge (66G, 500k files)
I 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.
my tool is not using regex, it can use regex but it is not required
Websites that don’t tell me what they’re doing are infuriating. I’m on mobile. This landing page experience is awful.
For desktops it's not different.
it is absolutely amazing experience on mobile if you guys do not understand how to use a search bar and a couple of segmeneted controls -- there is nothing much I can do about it
considering 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.
considering 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.
i see this - complaint? - often, but i use grep for finding text in files in the filesystem, like normal people. But specific datasets i'll use ag/rg. As an example, i have transcribed all of the "shows* i have access to for a couple of radio programs, when i want to do exploratory searches, i hit the set once with ag/rg, which takes 7-14 seconds to warm up once, then it's So while i'm sure ag/rg may be frustrating to use in certain circumstances, by default it works great for searching text files, even structured text files, on disk.