Issue with grep -i (on i386 only?)

[Mel Flynn-6]

Hi,

attached a little test script for grep's -i performance. I tried a few
different machines and the 64-bit 7.2 machine I could steal doesn't seem to be
affected and out performs pcregrep.
On i386 machines, grep -i is significantly slower:
i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00,
Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free
dev.cpu.0.freq: 2992 (Intel P-IV HTT enabled)
16Meg file result:
=>>> 16777216
    =>>> fgrep
        0.04 real         0.02 user         0.01 sys
        0.04 real         0.03 user         0.01 sys
    =>>> pcregrep
        0.21 real         0.19 user         0.02 sys
        0.21 real         0.20 user         0.00 sys
    =>>> grep
        0.04 real         0.02 user         0.01 sys << not -i
        3.64 real         3.61 user         0.01 sys << -i

i386, 8.0-RC1 FreeBSD 8.0-RC1 #15 r197337M, load averages: 1.61, 1.35, 1.12
Mem: 920M Active, 87M Inact, 215M Wired, 69M Cache, 112M Buf, 195M Free
dev.cpu.0.freq: 1733 (Intel dual core laptop)
16Meg file result:
=>>> 16777216
    =>>> fgrep
        0.04 real         0.02 user         0.01 sys
        0.05 real         0.04 user         0.00 sys
    =>>> pcregrep
        0.26 real         0.23 user         0.01 sys
        0.29 real         0.24 user         0.00 sys
    =>>> grep
        0.04 real         0.04 user         0.00 sys
        4.73 real         4.15 user         0.01 sys

amd64, 7.2-RELEASE-p4 #1 r198384M, load averages: 0.00, 0.00, 0.00
Mem: 115M Active, 182M Inact, 264M Wired, 101M Cache, 213M Buf, 1311M Free
CPU: Dual-Core AMD Opteron(tm) Processor 2210 (1800.08-MHz K8-class CPU)
64Meg file result:
=>>> 67108864
    =>>> fgrep
        0.18 real         0.13 user         0.04 sys
        0.19 real         0.17 user         0.02 sys
    =>>> pcregrep
        0.89 real         0.85 user         0.03 sys
        0.98 real         0.92 user         0.06 sys
    =>>> grep
        0.18 real         0.16 user         0.01 sys
        0.19 real         0.16 user         0.03 sys


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]

So it looks to me that, while there is a problem with case insensitive
comparison, just rewriting the expression is an optimization grep could
perform.
Either way, with the new text tools being written (done?) is this problem
being attacked, not fixable due to specifications or not considered an issue?
Any PR's needed / I missed? Patches to try?

[And it just occured to me bsdgrep is in ports]:
    =>>> bsdgrep
        0.93 real         0.74 user         0.00 sys
        4.80 real         4.33 user         0.02 sys
        4.97 real         4.34 user         0.01 sys

So here the optimization does not fly.
--
Mel

#!/bin/sh
# vim: ts=4 sw=4 noet tw=78 ai

PCREGREP=`which pcregrep`
BSDGREP=`which bsdgrep`
[ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}`
[ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}`

me=`basename $0`
BYTES="1048576 2097152 4194304 8388608 16777216"
if [ ! -x /usr/bin/jot ]; then
        echo "Need jot"
        exit 1
fi
if [ ! -x /usr/bin/rs ]; then
        echo "Need rs"
        exit 1
fi

for b in ${BYTES}; do
        TMPFILE=`mktemp -t ${me}`
        if [ ! -f ${TMPFILE} ]; then
                echo Can\'t create tmp files in ${TMPDIR:="/tmp"}
                exit 2
        fi
        jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE}
        echo "=>>> ${b}"
        for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do
                echo "    =>>> ${prog}"
                /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null
                /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null
                /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null
        done
        rm ${TMPFILE}
done


_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Gabor Kovesdan-3]

Mel Flynn escribió:
> Hi,
>
> attached a little test script for grep's -i performance. I tried a few
> different machines and the 64-bit 7.2 machine I could steal doesn't seem to be
> affected and out performs pcregrep.
>  
Note, that pcregrep isn't POSIX regex so it's not a good base of
comparison. PCRE provides a POSIX-compliant interface to deal with
Perl-compatible regex for those, who are already familiar with the
former but it's still Perl regex and not POSIX! That's why some people
get confused when PCRE comes to the topic.

> On i386 machines, grep -i is significantly slower:
> i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00,
> Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free
> dev.cpu.0.freq: 2992 (Intel P-IV HTT enabled)
> 16Meg file result:
> =>>> 16777216
>     =>>> fgrep
>         0.04 real         0.02 user         0.01 sys
>         0.04 real         0.03 user         0.01 sys
>     =>>> pcregrep
>         0.21 real         0.19 user         0.02 sys
>         0.21 real         0.20 user         0.00 sys
>     =>>> grep
>         0.04 real         0.02 user         0.01 sys << not -i
>         3.64 real         3.61 user         0.01 sys << -i
>  

It's an interesting observation, I have never heard of this.

> So it looks to me that, while there is a problem with case insensitive
> comparison, just rewriting the expression is an optimization grep could
> perform.
> Either way, with the new text tools being written (done?) is this problem
> being attacked, not fixable due to specifications or not considered an issue?
> Any PR's needed / I missed? Patches to try?
>
> [And it just occured to me bsdgrep is in ports]:
>     =>>> bsdgrep
>         0.93 real         0.74 user         0.00 sys
>         4.80 real         4.33 user         0.02 sys
>         4.97 real         4.34 user         0.01 sys
>
> So here the optimization does not fly.

Unfortunately, this is the most important issue with BSDL texttools. In
the grep case, the BSDL version is ready and feature-complete but the
performance isn't quite satisfying. The main reason of this is GNU grep
uses a lot of shortcuts, which results in a bloated code (8000 LOC),
while BSDL grep keeps everything simple and straightforward (1500 LOC).
IMO, the desired solution would be to keep grep small and get a modern
regex library for FreeBSD, which performs well. Pushing regex
optimizations into grep is a bad idea because it not just makes the code
bloated but other regex users won't benefit from the optimization so the
problem should be fixed at its roots. And the current regex library we
have is old, slow and doesn't support wchar, at all.

Btw, do you mind if I include your script into the BSD grep
distribution? I already planned to write something like this for future
testing.

--
Gabor Kovesdan
FreeBSD Volunteer

EMAIL: gabor@... .:|:. gabor@...
WEB:   http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Mel Flynn-6]

On Tuesday 03 November 2009 22:19:05 Gabor Kovesdan wrote:

> Mel Flynn escribió:
> > Hi,
> >
> > attached a little test script for grep's -i performance. I tried a few
> > different machines and the 64-bit 7.2 machine I could steal doesn't seem
> > to be affected and out performs pcregrep.
>
> Note, that pcregrep isn't POSIX regex so it's not a good base of
> comparison. PCRE provides a POSIX-compliant interface to deal with
> Perl-compatible regex for those, who are already familiar with the
> former but it's still Perl regex and not POSIX! That's why some people
> get confused when PCRE comes to the topic.

I realize this, but for the case in question it does not matter. Both
'regexes' should do the same in PCRE and POSIX. I provided the comparison to
show that the 'problem of case insensitive comparison' is solvable, at the
very least for the simple case.

> > On i386 machines, grep -i is significantly slower:
> > i386, 7.2-STABLE of Sep 8, load averages: 0.00, 0.02, 0.00,
> > Mem: 336M Active, 442M Inact, 217M Wired, 38M Cache, 112M Buf, 198M Free
> > dev.cpu.0.freq: 2992 (Intel P-IV HTT enabled)
> > 16Meg file result:
> > =>>> 16777216
> >     =>>> fgrep
> >         0.04 real         0.02 user         0.01 sys
> >         0.04 real         0.03 user         0.01 sys
> >     =>>> pcregrep
> >         0.21 real         0.19 user         0.02 sys
> >         0.21 real         0.20 user         0.00 sys
> >     =>>> grep
> >         0.04 real         0.02 user         0.01 sys << not -i
> >         3.64 real         3.61 user         0.01 sys << -i
>
> It's an interesting observation, I have never heard of this.
>
> > So it looks to me that, while there is a problem with case insensitive
> > comparison, just rewriting the expression is an optimization grep could
> > perform.
> > Either way, with the new text tools being written (done?) is this problem
> > being attacked, not fixable due to specifications or not considered an
> > issue? Any PR's needed / I missed? Patches to try?
> >
> > [And it just occured to me bsdgrep is in ports]:
> >     =>>> bsdgrep
> >         0.93 real         0.74 user         0.00 sys
> >         4.80 real         4.33 user         0.02 sys
> >         4.97 real         4.34 user         0.01 sys
> >
> > So here the optimization does not fly.
>
> Unfortunately, this is the most important issue with BSDL texttools. In
> the grep case, the BSDL version is ready and feature-complete but the
> performance isn't quite satisfying. The main reason of this is GNU grep
> uses a lot of shortcuts, which results in a bloated code (8000 LOC),
> while BSDL grep keeps everything simple and straightforward (1500 LOC).
> IMO, the desired solution would be to keep grep small and get a modern
> regex library for FreeBSD, which performs well. Pushing regex
> optimizations into grep is a bad idea because it not just makes the code
> bloated but other regex users won't benefit from the optimization so the
> problem should be fixed at its roots. And the current regex library we
> have is old, slow and doesn't support wchar, at all.

With this kind of difference, I don't really care who performs the
optimization, but it seems that multiple options at the same character spot is
not handled very well, with an extra penalty for "case insensitive".
Why this isn't present on my 64-bit machine is a bit of a mystery to me, but
since almost no time is spent in sys, I can't blame it on kernel.

> Btw, do you mind if I include your script into the BSD grep
> distribution? I already planned to write something like this for future
> testing.

Consider it public domain.
--
Mel
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Eygene Ryabinkin-3]

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.

> attached a little test script for grep's -i performance.

Some notes about the script, especially if (or some variant of it)
will be included to the testing framework.

> #!/bin/sh
> # vim: ts=4 sw=4 noet tw=78 ai
>
> PCREGREP=`which pcregrep`
> BSDGREP=`which bsdgrep`
> [ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}`
> [ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}`

You'll want '[ -n "${PCREGREP}" ] && ...' (with quoted variable) to
really achieve the kind of test you wanted.

> if [ ! -x /usr/bin/jot ]; then
> echo "Need jot"
> exit 1
> fi
> if [ ! -x /usr/bin/rs ]; then
> echo "Need rs"
> exit 1
> fi

Probably this is better be written as
-----
for prog in jot rs; do
        if [ -z "`which "$prog"`" ]; then
                echo "Need $prog"
                exit 1
        fi
done
-----
because the latter code uses unqualified 'jot' and 'rs'.

> for b in ${BYTES}; do
> TMPFILE=`mktemp -t ${me}`
> if [ ! -f ${TMPFILE} ]; then
> echo Can\'t create tmp files in ${TMPDIR:="/tmp"}
> exit 2
> fi
> jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE}
> echo "=>>> ${b}"
> for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do
> echo "    =>>> ${prog}"
> /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null
> /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null
> /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null
> done
> rm ${TMPFILE}
> done

Most likely, it is better to create the temporary file only once
and to trap the signals with the file removal -- this will handle
the cases when user presses ^C during the execution -- temporary
file should be cleaned in this case.  The code is simple:
-----
TMPFILE=`mktemp -t ${me}`
if [ ! -f ${TMPFILE} ]; then
        echo "Can't create tmp file in ${TMPDIR:=/tmp}"
        exit 2
fi
trap 'rm -f "${TMPFILE}"' 0 1 2 3 15
-----

Attaching modified version with the bonus -- 'K' and 'M' size prefixes:
it was boring to specify many digits when I had played with sizes ;))
--
Eygene
 _                ___       _.--.   #
 \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
 /  ' `         ,       __.--'      #  to read the on-line manual
 )/' _/     \   `-_,   /            #  while single-stepping the kernel.
 `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
     _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
    {_.-``-'         {_/            #

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Alex Burke]

On Wednesday, November 4, 2009, Eygene Ryabinkin <rea-fbsd@...> 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.
>
>> attached a little test script for grep's -i performance.
>
> Some notes about the script, especially if (or some variant of it)
> will be included to the testing framework.
>
>> #!/bin/sh
>> # vim: ts=4 sw=4 noet tw=78 ai
>>
>> PCREGREP=`which pcregrep`
>> BSDGREP=`which bsdgrep`
>> [ -n ${PCREGREP} ] && PCREGREP=`basename ${PCREGREP}`
>> [ -n ${BSDGREP} ] && BSDGREP=`basename ${BSDGREP}`
>
> You'll want '[ -n "${PCREGREP}" ] && ...' (with quoted variable) to
> really achieve the kind of test you wanted.
>
>> if [ ! -x /usr/bin/jot ]; then
>>       echo "Need jot"
>>       exit 1
>> fi
>> if [ ! -x /usr/bin/rs ]; then
>>       echo "Need rs"
>>       exit 1
>> fi
>
> Probably this is better be written as
> -----
> for prog in jot rs; do
>         if [ -z "`which "$prog"`" ]; then
>                 echo "Need $prog"
>                 exit 1
>         fi
> done
> -----
> because the latter code uses unqualified 'jot' and 'rs'.
>
>> for b in ${BYTES}; do
>>       TMPFILE=`mktemp -t ${me}`
>>       if [ ! -f ${TMPFILE} ]; then
>>               echo Can\'t create tmp files in ${TMPDIR:="/tmp"}
>>               exit 2
>>       fi
>>       jot -r -c ${b} a z |rs -g 0 20 > ${TMPFILE}
>>       echo "=>>> ${b}"
>>       for prog in fgrep ${PCREGREP} ${BSDGREP} grep ; do
>>               echo "    =>>> ${prog}"
>>               /usr/bin/time ${prog} foo ${TMPFILE} >/dev/null
>>               /usr/bin/time ${prog} -i foo ${TMPFILE} >/dev/null
>>               /usr/bin/time ${prog} '[fF][Oo][Oo]' ${TMPFILE} >/dev/null
>>       done
>>       rm ${TMPFILE}
>> done
>
> Most likely, it is better to create the temporary file only once
> and to trap the signals with the file removal -- this will handle
> the cases when user presses ^C during the execution -- temporary
> file should be cleaned in this case.  The code is simple:
> -----
> TMPFILE=`mktemp -t ${me}`
> if [ ! -f ${TMPFILE} ]; then
>         echo "Can't create tmp file in ${TMPDIR:=/tmp}"
>         exit 2
> fi
> trap 'rm -f "${TMPFILE}"' 0 1 2 3 15
> -----
>
> Attaching modified version with the bonus -- 'K' and 'M' size prefixes:
> it was boring to specify many digits when I had played with sizes ;))
> --
> Eygene
>  _                ___       _.--.   #
>  \`.|\..----...-'`   `-._.-'_.-'`   #  Remember that it is hard
>  /  ' `         ,       __.--'      #  to read the on-line manual
>  )/' _/     \   `-_,   /            #  while single-stepping the kernel.
>  `-'" `"\_  ,_.-;_.-\_ ',  fsc/as   #
>      _.-'_./   {_.'   ; /           #    -- FreeBSD Developers handbook
>     {_.-``-'         {_/            #
>

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Mel Flynn-6]

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
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

[Mel Flynn-6]

On Wednesday 04 November 2009 13:49:54 Mel Flynn wrote:

> 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.

It hit me. Rather then a local problem, it's a locale problem:
=>>> 16777216
    =>>> en_US.UTF-8
        =>>> fgrep
        0.04 real         0.04 user         0.00 sys
        0.04 real         0.02 user         0.02 sys
        0.02 real         0.01 user         0.00 sys
        =>>> grep
        0.04 real         0.04 user         0.00 sys
        3.74 real         3.55 user         0.02 sys
        1.95 real         1.83 user         0.03 sys
    =>>> en_US.ISO8859-1
        =>>> fgrep
        0.04 real         0.04 user         0.00 sys
        0.04 real         0.03 user         0.00 sys
        0.02 real         0.01 user         0.01 sys
        =>>> grep
        0.05 real         0.03 user         0.00 sys
        0.05 real         0.04 user         0.00 sys
        0.08 real         0.04 user         0.03 sys
    =>>> en_US.US-ASCII
        =>>> fgrep
        0.04 real         0.01 user         0.02 sys
        0.05 real         0.03 user         0.01 sys
        0.02 real         0.00 user         0.02 sys
        =>>> grep
        0.04 real         0.03 user         0.00 sys
        0.05 real         0.03 user         0.00 sys
        0.08 real         0.06 user         0.01 sys

--
Mel
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."