sbw@naucse.UUCP (Steve Wampler) (12/09/88)
In every machine I've played with, fgrep has never
performed better than plain old grep for any data I've given
it (and on some machines, it is *considerably* slower).
Is there ever a situation (these days) where fgrep is
preferable to grep? About the only thing that remotely
comes to my mind is that you don't have to worry quite
so much about escaping metacharacters, but I always
quote literal strings anyway.
Just curious.
--
Steve Wampler
{....!arizona!naucse!sbw}dhesi@bsu-cs.UUCP (Rahul Dhesi) (12/09/88)
In article <1050@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: >In every machine I've played with, fgrep has never >performed better than plain old grep for any data I've given >it (and on some machines, it is *considerably* slower). It performs well if you have a large number of strings to look for. For example: cat longfile | fgrep -f stoplist | other_stuff In one experiment on a VAX-11/785 (4.3BSD), with 470 entries in 'longfile' and 20 search strings in 'stoplist', fgrep did it in 2 seconds real time while egrep took 10. User/system cpu times were correspondingly different. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/09/88)
In article <1050@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: >Is there ever a situation (these days) where fgrep is >preferable to grep? Yes, fgrep 'word1 word2 ... wordn' files ... Be advised that work is underway at Bell Labs to merge all the greps into a single utility.
debra@alice.UUCP (Paul De Bra) (12/10/88)
In article <1050@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: >In every machine I've played with, fgrep has never >performed better than plain old grep for any data I've given >it (and on some machines, it is *considerably* slower). >... > >Just curious. No big deal I would say: I did a short comparison by searching for a fixed 6 character string in a bunch of C-files. grep took 10 times longer than gre, and fgrep took 14 times longer than gre... too bad gre is not PD I believe... Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
jaw@eos.UUCP (James A. Woods) (12/10/88)
> too bad gre is not PD I believe... > yes, at&t has a problem not only when others beat them to the punch in implementing fast algorithms ("old" fast [ef]?grep, GNU e?grep, GNU diff, fastfind, compress ...), but give them away to the world to boot. most people will find the free gnu e?grep quite serviceable (the 10x speedup particularly pleases the cray community), especially with the handy context option, much more valuable than other flags. it's been an "anonymous ftp" item on prep.ai.mit.edu for some time. i write as someone who admires hume's work, but recognizes the world doesn't have to wait for any decent code which might crop up in sys5r4. btw, 'gre' is a horrible name; for something that's plug compatible, educating purist oldtimers to change now will be difficult (though many folks currently alias fast grep to 'g', anyhow). ames!jaw
andrew@alice.UUCP (Andrew Hume) (12/12/88)
steve wampler asks why would you ever use fgrep rather than grep? despite the fact that he has never seen fgrep run faster than grep, it often does run faster. that's one reason. the more important reason is that fgrep searches for any element of a list of literal strings, something that grep simply cannot do. furthermore, it does it MUCH faster than egrep does. of course, new techniques allow fgrep to run about four times faster still.
andrew@alice.UUCP (Andrew Hume) (12/12/88)
it seems that eventually gre (merely an internal name; it will appear as grep) will surface as at&t code. gnu egrep seems a good reimplementation; all that is missing is the commentz-walter stuff to do teh fgrep stuff. i have talked with haertal (sic?) at gnu about this; it may appear at some point. in any case, i intend to publish a full description of the commentz-wlater stuff soon so someone (perhaps berkeley) can issue a pd version.
paulb@ttidca.TTI.COM (Paul Blumstein) (12/13/88)
In article <9116@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: +In article <1050@naucse.UUCP> sbw@naucse.UUCP (Steve Wampler) writes: +>Is there ever a situation (these days) where fgrep is +>preferable to grep? + +Yes, + fgrep 'word1 + word2 + ... + wordn' files ... + Make that: fgrep 'word1\ word2\ ... wordn' file1 ... You need that \ to tell the shell that more is coming (csh, anyway). ============================================================================= Paul Blumstein | Aunt Em: Hate you. Hate Kansas. Took the dog. Citicorp/TTI | -- Dorothy Santa Monica, CA +------------------------------------------------- {philabs,csun,psivax}!ttidca!paulb or paulb@ttidca.TTI.COM If caught, the Secretary of Citicorp will disavow all knowledge of my actions.
gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/16/88)
In article <3550@ttidca.TTI.COM> paulb@ncc1701.tti.com (Paul Blumstein) writes: >You need that \ to tell the shell that more is coming (csh, anyway). Regular readers of this newsgroup should know that my examples are always for a Bourne shell environment. Cshell sucks.
guy@auspex.UUCP (Guy Harris) (12/17/88)
>You need that \ to tell the shell that more is coming (csh, anyway).
But not "sh"; it allows un-escaped backslashes in strings.rml@hpfcdc.HP.COM (Bob Lenk) (12/23/88)
Another reason to use fgrep in some places is that it does no regular expression matching. This makes it suitable for matching arbitrary strings that may contain metacharacters. Bob Lenk hplabs!hpfcla!rml rml%hpfcla@hplabs.hp.com