Bug 90109 - grep 2.5 slow
grep 2.5 slow
 Status: CLOSED DUPLICATE of bug 69900 None Red Hat Linux Retired grep (Show other bugs) --- 9 i686 Linux medium medium --- Tim Waugh Mike McLean depends on / blocked

 Reported: 2003-05-02 16:59 UTC by Phil Moses 2007-04-18 16:53 UTC (History) 2 users (show) mitr twaugh Bug Fix --- 2006-02-21 18:52:52 UTC --- --- --- --- --- --- ---

 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..... #!/bin/csh set i = 0 \rm test.dat echo 0>! test.dat while ($i < 100000 ) set i = expr$i + 1  echo $i >> test.dat end time grep 99999 test.dat Version-Release number of selected component (if applicable): grep (GNU grep) 2.5.1 How reproducible: Always 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 noticed.  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?  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.  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 ***  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 2.4 [pmoses@ironcity TESTS]$ ./greptest24.sh 99999 0.000u 0.003s 0:00.05 0.0% 0+0k 0+0io 124pf+0w 2.5 [pmoses@ironcity TESTS]$./greptest.sh 99999 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 99999 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.  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.  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 expected. *** This bug has been marked as a duplicate of 69900 ***  Red Hat Bugzilla 2006-02-21 18:52:52 UTC Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.