Issue with grep -i (on i386 only?)

[Mel Flynn]

On Wednesday 04 November 2009 04:05:44 Eygene Ryabinkin wrote:
> Mel, good day.
> 
> Tue, Nov 03, 2009 at 09:22:28PM +0100, Mel Flynn wrote:
> > So on the laptop I modified the testscript as it is attached now and
> > while there is still a significant delay, the wallclock time is less
> > then half, when the expression is rewritten with the same meaning:
> > =>>> 16777216
> >     =>>> fgrep
> >         0.04 real         0.03 user         0.00 sys
> >         0.05 real         0.03 user         0.01 sys
> >         0.02 real         0.00 user         0.00 sys
> >     =>>> pcregrep
> >         0.26 real         0.21 user         0.02 sys
> >         0.26 real         0.22 user         0.02 sys
> >         0.44 real         0.35 user         0.01 sys
> >     =>>> grep
> >         0.04 real         0.04 user         0.00 sys
> >         4.45 real         4.15 user         0.01 sys
> >         2.00 real         1.81 user         0.00 sys <-- [fF][Oo][Oo]
> 
> Just did a quick test on the 8.0-RC2/i386 with very old Athlon processor:
> -----
> =>>> 16777216
>     =>>> fgrep
>         0,09 real         0,04 user         0,05 sys
>         0,18 real         0,06 user         0,03 sys
>         0,05 real         0,01 user         0,04 sys
>     =>>> pcregrep
>         0,47 real         0,29 user         0,07 sys
>         0,52 real         0,33 user         0,07 sys
>         0,77 real         0,45 user         0,03 sys
>     =>>> grep
>         0,09 real         0,08 user         0,01 sys
>         0,10 real         0,04 user         0,05 sys
>         0,23 real         0,12 user         0,03 sys
> -----
> Pattern for the plain 'grep' is stable: first and second variants always
> give the same time within a 0.01 second variation and the last variant
> gives 2x slowdown.
> 
> I tried sizes up to the 64M -- the pattern stays.  The same stuff for
> the amd64, so in my case I don't see the difference in behaviour.  So,
> maybe, the problem isn't 32 vs 64 but lies somewhere else.

Well, just ruled out the last commonality: The i386 machines tested all had 
MAXPHYS to 1M, except the one I just tried:
=>>> 16777216
    =>>> fgrep
        0.04 real         0.03 user         0.00 sys
        0.04 real         0.03 user         0.00 sys
        0.02 real         0.00 user         0.01 sys
    =>>> grep
        0.04 real         0.02 user         0.02 sys
        3.70 real         3.56 user         0.00 sys
        1.91 real         1.83 user         0.02 sys

Using env MALLOC_OPTIONS= also has no impact at all (just in case defaults 
aren't that). Since fgrep is fast and basically seeds the cache for grep, I'm 
ruling out disks/io reads. In fact, /tmp on this laptop is memory disk (one 
reason I couldn't go up to 64M :)). I honestly can't figure out what my 'local 
problem' could be or your optimization.

Thanks for the fix ups. One more below sig.
-- 
Mel

--- grep-test.sh.orig   2009-11-04 03:17:05.000000000 -0900
+++ grep-test.sh        2009-11-04 03:29:55.000000000 -0900
@@ -34,6 +34,10 @@
                ;;
        esac

+       if [ ! -f ${TMPFILE} ]; then
+               # signalled
+               exit 0;
+       fi
        jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE}
        echo "=>>> ${b}"
        for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do