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.
Please be a bit more quantitative. Are we talking about a 100-fold decrease in speed here, or something less?
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.
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 ***
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.
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.
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 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.