3 ms·

I think it would be interesting to compare those utilities with GNU grep on a single file, because I understand them to be faster on many files because they (1)

I think it would be interesting to compare those utilities with GNU grep on a single file, because I understand them to be faster on many files because they (1) search files in parallel and (2) skip many uninteresting files automatically. I also don't think either of those tools are DFA based like GNU grep. One thing I'd like to see is combine many of the performance tricks found in GNU grep with the aforementioned (1)+(2) techniques. > You could make `grep` faster by telling it to interpret the pattern as a fixed string (-F or --fixed-strings) is you're not using a regex. That doesn't really make much sense. GNU grep can tell whether a pattern is just a literal or not. If it's a literal, it should be able to stay out of the main DFA engine entirely.

gpderetta 10y ago
I use grep for single files (mostly because it is burned in my muscle memory). The silver searcher (from emacs) for bulk searches in a large directory tree (like a codebase).
nilved 10y ago
It's pretty easy to use grep and search in parallel while skipping uninteresting files. `git ls-files | xargs -P4 -n8 grep whatever` is a good way to do this; or `git grep`, but that's using PCRE and not parallelized. > That doesn't really make much sense. GNU grep can tell whether a pattern is just a literal or not. If it's a literal, it should be able to stay out of the main DFA engine entirely. That would be clever but it doesn't do that.
- goldenkey 10y ago
  The regex is compiled anyhow to a C-call subroutine using a lib. So the overhead is only a function call. I highly doubt a single inlined proc is going to give much speed gain.
- burntsushi 10y ago
  > That would be clever but it doesn't do that. Really? Pretty sure it does. Have you read the source code? There is a specific part that looks to see if it has a literal and will use that. If it has an exact match, then it will skip the DFA completely.
0xmohit 10y ago
> That doesn't really make much sense. GNU grep can tell whether a pattern is just a literal or not. It does help when the search string comprises of regex metacharacters and you actually wanted a literal search.

gpderetta 10y ago

I use grep for single files (mostly because it is burned in my muscle memory). The silver searcher (from emacs) for bulk searches in a large directory tree (like a codebase).

nilved 10y ago

It's pretty easy to use grep and search in parallel while skipping uninteresting files. `git ls-files | xargs -P4 -n8 grep whatever` is a good way to do this; or `git grep`, but that's using PCRE and not parallelized. > That doesn't really make much sense. GNU grep can tell whether a pattern is just a literal or not. If it's a literal, it should be able to stay out of the main DFA engine entirely. That would be clever but it doesn't do that.

goldenkey 10y ago
The regex is compiled anyhow to a C-call subroutine using a lib. So the overhead is only a function call. I highly doubt a single inlined proc is going to give much speed gain.
burntsushi 10y ago
> That would be clever but it doesn't do that. Really? Pretty sure it does. Have you read the source code? There is a specific part that looks to see if it has a literal and will use that. If it has an exact match, then it will skip the DFA completely.

0xmohit 10y ago

> That doesn't really make much sense. GNU grep can tell whether a pattern is just a literal or not. It does help when the search string comprises of regex metacharacters and you actually wanted a literal search.