Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!ox.com!math.fu-berlin.de!fub!geminix.in-berlin.de!gemini From: gemini@geminix.in-berlin.de (Uwe Doering) Newsgroups: news.software.b Subject: Re: egrep hazardrous to your system's cnews health Message-ID: <2UVQZ1H@geminix.in-berlin.de> Date: 13 May 91 13:12:45 GMT References: <1991May11.040314.15393@colnet.uucp> Organization: Private UNIX Site Lines: 35 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. I found this to be true on ISC UNIX 386, too. I changed most occurences of `egrep' to `grep' (at least where no special features of `egrep' were used). Since then, batching runs much faster. Uwe -- Uwe Doering | INET : gemini@geminix.in-berlin.de Berlin |---------------------------------------------------------------- Germany | UUCP : ...!unido!fub!geminix.in-berlin.de!gemini