fgrep (isn't)

[Spencer W. Thomas]

Not to continue flogging a dead horse, but I think (mixing my
metaphors), I may be able to shed a little more light here.  (Then
again, maybe not.)

In article <507 at unisoft.UUCP> fnf at unisoft.UUCP (Fred Fish) writes:
>From the system V User's Manual grep(1):
>...
>	"Egrep patterns are full regular *expressions*..."

You didn't quote the relevant part about egrep (unless this has been
deleted from the SYS V manual).  The '...' expands to
	"it uses a fast deterministic algorithm..."
When read carefully, this indicates that egrep has the potential of
being faster.  The problem with egrep is
	"that [it] sometimes needs exponential space."

Timings of '*grep foo *' on a large directory yield the information

egrep	5.8u 1.6s 0:17 41% 19+40k 217+13io 2pf+0w
grep	7.0u 1.7s 0:34 25% 7+15k 225+22io 1pf+0w
fgrep	10.0u 1.8s 0:47 24% 7+15k 211+7io 3pf+0w

showing `clearly' the superiority of egrep in this case.

I think that in Fred's example, the setup time for egrep may have
overwhelmed the search time (that's the only theory I can think of,
anyway), so that perhaps grep is better for single file searches, but it
has been our experience that egrep is better when searching over a large
number of files.  (To forstall the obvious followups:)  It seems clear,
from previous postings, that 'bm' or 'bgrep' are better for the simple
case of searching for strings.

-- 
=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas at utah-cs.ARPA)
	"You don't get to choose how you're going to die.  Or when.
	 You can only decide how you're going to live." Joan Baez