Robert Newson wrote: [...] > > When testing out the various versions of grep (grep, egrep, fgrep) on > Unix, I ran the timings at least twice - first to ensure that the > command and data were in memory & cached and ignored that time, and > then a second (or more) time(s) for the actual timing. Including the > first run would make the comparison skewed as the data for second > program would be cached after testing first program, plus I preferred > to do several timings and take the mean (the first timing would be > larger due to the program not being cached). [If you're interested, I > found egrep to be the fasted for the grepping I do.]
Perhaps because the egrep that you tried used a DFA RE engine, DFA engines are generally slower to compile the REs, but faster in operation, than the NFA engines used in many grep implementations (this problem is especially noticeable with POSIX NFA engines because they must try all possible matches). Interestingly I've often found that fgrep is sometimes slower than running egrep with the same parameters, which is odd because it is named f(ast)grep, and was clearly intended to be used for pure string searches. In theory I suppose "pure", i.e., non-RE, string searches ought to be faster than RE searches, but clearly not by much in this case: $ time egrep "susp" .bash_profile susp() ## print the POSIX man page for $1 to $1.posix export -f l path substr sus wd awd susp real 0m1.487s user 0m0.000s sys 0m0.000s $ time fgrep "susp" .bash_profile susp() ## print the POSIX man page for $1 to $1.posix export -f l path substr sus wd awd susp real 0m1.269s user 0m0.000s sys 0m0.000s $ As you say a lot depends on the type of searching that you are doing and the system that you are using. -- Peter S Tillier "Who needs perl when you can write dc, sokoban, arkanoid and an unlambda interpreter in sed?"
