3 ms·

I use this an ripgrep. By default I tend to use ripgrep. It skips various files, e.g. tarballs, ".git", ".svn" and so on. It's quite quick as a result. I also l

by bkor 6y ago

I use this an ripgrep. By default I tend to use ripgrep. It skips various files, e.g. tarballs, ".git", ".svn" and so on. It's quite quick as a result. I also like the output a lot, though it's kind of annoying that the output format changes when output to the screen vs when redirected (e.g. to a pipe). It would be nicer if ripgrep always redirected things through less with colours (the way that git does it). Ugrep is great because it can grep through tarballs. But the default output format of ripgrep is nicer, plus ripgrep seems quicker when searching recursively with loads of files that could be skipped (so tarballs, etc). I'm guessing ugrep skips less files.

burntsushi 6y ago
I'm sure there are some cases where the performance difference comes down to skipping more or fewer files, but there's a lot more to it than that. In many cases, skipping files is actually slower! I did some analysis here: https://www.reddit.com/r/rust/comments/i6pfb2/ugrep_new_ultrafast_c_grep_claims_to_be_faster/g0xybge https://www.reddit.com/r/rust/comments/i6pfb2/ugrep_new_ultr... > It would be nicer if ripgrep always redirected things through less with colours (the way that git does it). The -p flag should help there. Disclaimer: I am the author of ripgrep.
- bkor 6y ago
  > I'm sure there are some cases where the performance difference comes down to skipping more or fewer files My use case if probably weird, various times I grep for things across about 13k of full rpm package checkouts. So 13k directories, each with their .svn directory, one or more tarballs, possibly some patches/scripts, plus a spec file. I used to specifically tell GNU grep what to search for (grep something /SPECS/.spec), partly to avoid getting too many unwanted matches. Ripgrep is smart and quick enough to not need anything special. I like ugrep because sometimes it's needed to check the sources as well. Total size is 50-70GB, the spec files make up a tiny bit of that. The distribution recently added a daily updated tarball with just the specs (7 or 20MB compressed depending if the .svn is in there). I'm planning to switch over to that. I'll spare you the details for why it's more difficult than it seems. Thanks for the -p advice!
  - burntsushi 6y ago
    Gotya, thanks for elaborating! In case you didn't know about it, there is also ripgrep-all, which uses ripgrep internally, but can also search oodles of non-plain-text files, including tarballs: https://github.com/phiresky/ripgrep-all https://github.com/phiresky/ripgrep-all

by bkor 6y ago

burntsushi 6y ago

I'm sure there are some cases where the performance difference comes down to skipping more or fewer files, but there's a lot more to it than that. In many cases, skipping files is actually slower! I did some analysis here: https://www.reddit.com/r/rust/comments/i6pfb2/ugrep_new_ultrafast_c_grep_claims_to_be_faster/g0xybge https://www.reddit.com/r/rust/comments/i6pfb2/ugrep_new_ultr... > It would be nicer if ripgrep always redirected things through less with colours (the way that git does it). The -p flag should help there. Disclaimer: I am the author of ripgrep.

bkor 6y ago
> I'm sure there are some cases where the performance difference comes down to skipping more or fewer files My use case if probably weird, various times I grep for things across about 13k of full rpm package checkouts. So 13k directories, each with their .svn directory, one or more tarballs, possibly some patches/scripts, plus a spec file. I used to specifically tell GNU grep what to search for (grep something /SPECS/.spec), partly to avoid getting too many unwanted matches. Ripgrep is smart and quick enough to not need anything special. I like ugrep because sometimes it's needed to check the sources as well. Total size is 50-70GB, the spec files make up a tiny bit of that. The distribution recently added a daily updated tarball with just the specs (7 or 20MB compressed depending if the .svn is in there). I'm planning to switch over to that. I'll spare you the details for why it's more difficult than it seems. Thanks for the -p advice!
- burntsushi 6y ago
  Gotya, thanks for elaborating! In case you didn't know about it, there is also ripgrep-all, which uses ripgrep internally, but can also search oodles of non-plain-text files, including tarballs: https://github.com/phiresky/ripgrep-all https://github.com/phiresky/ripgrep-all