Bug 90109 - grep 2.5 slow
Summary: grep 2.5 slow
Status: CLOSED DUPLICATE of bug 69900
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: grep (Show other bugs)
(Show other bugs)
Version: 9
Hardware: i686 Linux
Target Milestone: ---
Assignee: Tim Waugh
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-05-02 16:59 UTC by Phil Moses
Modified: 2007-04-18 16:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 18:52:52 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Phil Moses 2003-05-02 16:59:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Gnu grep 2.5.1 provided with RH 9.0 is much slower than grep 2.4

I have adjusted LAN and LC_ALL variables, as they seemed to have created
problems in the past. I have tested this on Intel and AMD based machines, a
simple script to test follows, while it is a simple small test, it shows that
2.4 is much faster than 2.5, using a larger data set produces greater results.....
set i = 0
 \rm test.dat
 echo 0>! test.dat
   while ($i < 100000 )
    set i = `expr $i + 1 `
    echo $i >> test.dat

time grep 99999 test.dat

Version-Release number of selected component (if applicable):
grep (GNU grep) 2.5.1

How reproducible:

Steps to Reproduce:
1.install grep 2.4 and 2.5

2. Run the script
3. Compare results

Actual Results:  2.4 was faster than grep 2.5

Expected Results:  I would imagine on the same machine (offline, minimal
processes running) that the times should be equal.

Additional info:

LC_ALL and LANG variables were changed to see if this had an effect, none were

Comment 1 Tim Waugh 2003-05-06 10:10:38 UTC
Please be a bit more quantitative.  Are we talking about a 100-fold decrease in
speed here, or something less?

Comment 2 Phil Moses 2003-05-06 14:34:14 UTC
Im not sure how to respond to this; while I haven't seen speeds decrease by 100
fold I have seen in the 10-20 fold decrease of speeds. While this may seem
minuscule when dealing with a small file, it becomes more and more of a problem
as a data set grows.

Comment 3 Tim Waugh 2003-05-06 14:59:48 UTC
How exactly were you setting LANG?  I see no difference in elapsed time between:

time sh -c 'LANG=C grep 9999 test.dat'

for 2.4.2 and 2.5.1.

Think you're probably seeing UTF-8 locale processing.

*** This bug has been marked as a duplicate of 69900 ***

Comment 4 Phil Moses 2003-05-06 15:45:48 UTC
While this is claimed to be resolved and a duplicate bug, I am curious as to why
the user time is still higher (albeit by a much lower factor) than it is in 2.4.
Following are three results, using 2.4, 2.5 with UTF-8 and 2.5 with the LANG=C

[pmoses@ironcity TESTS]$ ./greptest24.sh
0.000u 0.003s 0:00.05 0.0%      0+0k 0+0io 124pf+0w

[pmoses@ironcity TESTS]$ ./greptest.sh
0.066u 0.000s 0:00.10 60.0%     0+0k 0+0io 150pf+0w

2.5 w/LANG=C
[pmoses@ironcity TESTS]$ ./greptestLANG.sh
0.001u 0.001s 0:00.04 0.0%      0+0k 0+0io 358pf+0w

Also, I agree with what was said in bug 69900, out of the box 2.5 is unusable
for many shell applications, this somewhat stinks, not that haing to make the
change is that big of a deal. Still curious of why the user time is higher though.

Comment 5 Tim Waugh 2003-05-06 16:14:05 UTC
As I said: I see no difference in elapsed time in my testing.  Maybe you should
try a larger file, and several runs (to cache the file contents etc).

So, I don't see the difference between this bug and bug 69900 right now.

Comment 6 Phil Moses 2003-05-06 18:59:04 UTC
Upon further testing, you are correct. 
Previously I had set LANG=C, possibly it was not getting exported to subprocesses. 
While running with "time sh -c 'LANG=C grep 9999 test.dat'" everything works as

*** This bug has been marked as a duplicate of 69900 ***

Comment 7 Red Hat Bugzilla 2006-02-21 18:52:52 UTC
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.