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