


(System time and wall-clock time were significantly higher the first few runs, when the data was being read from an SSD.) In contrast, “rg ‘foo bar’ m*.20o” reported 1.39 seconds of user-space time, 6.62 seconds system time, and 0.699 seconds total time - 1145% of a CPU core! On a Linux workstation with 64 GiB RAM, working on 42 GB of data across 284 files, “grep ‘foo bar’ m*.20o” reported 0.76 seconds of user-space time, 3.68 seconds system time, and 4.448 seconds total time, to process about 42 GB of data cached in memory. I never benchmarked it before, but for comparison: It also has some more user-friendly features, like defaulting to recursive search and ignoring. Ripgrep is often advocated as being a faster version of grep, thanks to just-in-time compilation of the regular expression matcher and parallel execution. Because the GOW project provides light-weight ports of Gnu tools to Windows, it’s understandable that it would not include some of the optimizations in Gnu’s implementation of grep. When I used grep from GOW the -F flag made the search 24 times faster. I got similar results when I was using Linux (WSL) on my computer. I used the -f to tell grep the name of a file containing the terms to search for, not to be confused with the additional flag -F to tell grep that the search terms are simply strings. Maybe it scans the regular expression(s) before searching and effectively sets the -F flag itself if appropriate.

Now grep is smart enough to search for strings quickly without having to be told explicitly via -F that the regular expressions are in fact strings. I suspect that the performance difference between fgrep and grep used to be larger, but the latter has gotten more efficient. There may be instances where fgrep is much faster than grep, but I haven’t seen one first hand. I ran an analogous search on my own computer with different data and got similar results. When I timed it the difference was on the order of 1%. It was a tiny bit faster, not enough to notice. This is the kind of task where fgrep (“fast grep”) is supposed to be much faster than grep. I was working on a project for a client where I had to search for a long list of words in a long list of files. These variants are deprecated, but are provided for backward compatibility. In addition, the variant programs egrep, fgrep and rgrep are the same as grep -E, grep -F, and grep -r, respectively. On Linux, if you ask for the man (manual) page for fgrep you’ll be taken to the man page for grep which says Strictly speaking I used grep -F rather than fgrep. However, if your regular expressions are in fact simply text strings, fgrep may be much faster than grep. The grep utility searches text files for regular expressions, but it can search for ordinary strings since these strings are a special case of regular expressions.
