Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!n8emr!colnet!res
From: res@colnet.uucp (Rob Stampfli)
Newsgroups: news.software.b
Subject: egrep hazardrous to your system's cnews health
Message-ID: <1991May11.040314.15393@colnet.uucp>
Date: 11 May 91 04:03:14 GMT
Organization: Little to None
Lines: 28

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?
-- 
Rob Stampfli, 614-864-9377, res@kd8wk.uucp (osu-cis!kd8wk!res), kd8wk@n8jyv.oh