rmk@rmkhome.UUCP (Rick Kelly) (05/14/91)
In article <1991May11.040314.15393@colnet.uucp> res@colnet.uucp (Rob Stampfli) writes: >I recently added /usr/lib/newsbin to my default search path, so I could use >the 'queuelen' command to see what was going on with the batcher. I found, >in the process, that the performance of this command was abysmal. Why, >'uustat' is significantly faster by comparison. > >Looking at the 'queuelen' script, I found that lo-and-behold, it wasn't >really that complicated. The culprit turns out to be egrep. There is >apparently something mightily inefficient with the way this command does >some searches. The pertinent point is that the string: > > ls | egrep "^C\..*$grade....\$" | wc | awk '{print $1}' > >took 22+ seconds to execute on my Unix-PC (16 entries in the directory). >Changing egrep to grep caused the execution time to take a more reasonable >2 secs. > >The problems with the egrep command inefficiency seems to be most exacerbated >by that the four '.'s (match any character) after $grade, which seems to put >egrep in an almost infinite loop. > >Is this true on other systems? I noticed that cnews tends to use egrep >rather copiously. Most of the instances could as easily use grep. I am >tempted to start a wholesale replacement. > >BTW, I am running cnews with patches thru 12/90. The system is a Unix-PC with >3.51 (s5r2) Unix. Any sage advice? I always thought that egrep was a "faster" grep. I guess I will have to do my own set of timing experiments. Unless there is something funny about egrep on the Unix-PC. Rick Kelly rmk@rmkhome.UUCP frog!rmkhome!rmk rmk@frog.UUCP