Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!bloom-beacon!think!ames!aurora!jaw
From: jaw@aurora.UUCP (James A. Woods)
Newsgroups: comp.sources.d
Subject: Re: Fastest `grep'?? Really? - (nf)
Message-ID: <725@aurora.UUCP>
Date: Wed, 24-Jun-87 17:40:45 EDT
Article-I.D.: aurora.725
Posted: Wed Jun 24 17:40:45 1987
Date-Received: Fri, 26-Jun-87 06:06:35 EDT
References: <7200003@iaoobelix.UUCP>
Organization: NASA Ames Research Center, Mt. View, Ca.
Lines: 31

The concocted example indeed makes grep spend much time searching for nothing.

Now, if you want to play the "worst case" game, tell me why, on a
vax 11/750 (bsd 4.3, fujitsu eagles), we get

	% time /bin/grep '....stuff' /usr/dict/words
	foodstuff
	22.2u 1.1s 0:44 
but
	% time grep '....stuff' /usr/dict/words
	foodstuff
	0.4u 0.4s 0:01

using my code.  Reasons for such disparity can be gleaned from the writeups
pep4grep.doc[1-4], bundled into the comp.sources shar.  As stated there,
cases can be "cooked" to show any of the algorithms in a bad light.

The newer [ef]?grep remains nonpareil for a vast majority of typical search
patterns, including but not limited to:

	expressions containing few or no metacharacters.
	    (thus obsoleting 'bm', 'match', etc.)
	complicated patterns with closures, but containing
	    nontrivial "must match" substring residue.
	meta-free kanji input.
	fgrep-style alternations of low cardinality.

[ef]?grep users who get strange results from the distributed eg.shell
test script, or have other suggestions, may write to:

ames!jaw