bug#21700: new snapshot available: grep-2.21.78-7da30

[Jim Meyering]

On Wed, Oct 21, 2015 at 1:09 PM, Gary Johnson <address@hidden> wrote:
> On 2015-10-18, Jim Meyering wrote:
>> > I built the snapshot on two systems, a fairly old one running Ubuntu
>> > 10.04.4 and a newer one running an up-to-date Linux Mint 17.2.
>> > 'make check' reported the same two failures on both:
>> >
>> >    XFAIL: backref-alt
>> >    XFAIL: triple-backref
>>
>> Thanks for building and reporting.
>> Each of those "XFAIL"s indicates an expected failure, so that is the
>> expected test result, for now.
>
> OK, thanks.
>
> I also built the snapshot successfully on a Fedora 17 system that I
> use for real work.  I just ran a performance test, FWIW.  I searched
> recursively in our source hierarchy of 6044 regular files and 1102
> directories for a simple string.
>
>     time grep -Rin mystring src > /dev/null
>
> Here are the results, averaged over three trials each, not including
> any slow times clearly due to updating caches.
>
>             2.12    2.21    2.21.78-7da30
>             -----   -----   -----
>     real    18.0s   1.08s   2.36s
>     user    17.8s   0.96s   2.24s
>     sys     0.12s   0.11s   0.10s
>
> Version 2.12 was /bin/grep.  The other two versions I built myself.

Thank you for the timings. Next time, please include the following:
  - CPU type/speed
  - file system type (and SSD or spinning rust)
  - OS version
  - options with which you configured/built grep
  - your current locale

While you see a performance degradation going from 2.21 to the
first 2.22 release candidate, I see the opposite trend, albeit barely
measurable:

Searching the following hierarchies, I see a consistent 1% improvement
going from 2.21 to 2.22 on an Intel(R) Core(TM) i7-4770S CPU @ 3.10GHz.
The files I searched were on an ext4 file system residing on an SSD
(OCZ-VERTEX3).
This system is using fedora rawhide.

$ find [a-g]* -type f|wc -l
335065
$ find [a-g]* -type d|wc -l
9667
$ du -shc [a-g]*
25M     autoconf
125M    automake
129M    bison
74M     cppi
437M    cu
103M    diffutils
732M    emacs
2.3G    gcc
345M    glibc
252M    gnulib
187M    grep
90M     gzip
4.7G    total

Both grep binaries were compiled with gcc-6.0.something (built from git)
using ./configure --enable-gcc-warnings && make

Here are best-of-3 timings running this command:

  env LC_ALL=en_US.UTF-8 time grep -ri mystring [a-g]* > /dev/null

grep-2.21: 8.05user 1.10system 0:09.17elapsed 99%CPU
(0avgtext+0avgdata 32876maxresident)k
0inputs+0outputs (0major+9986minor)pagefaults 0swaps

grep-2.22: 8.04user 1.04system 0:09.10elapsed 99%CPU
(0avgtext+0avgdata 32940maxresident)k
0inputs+0outputs (0major+9988minor)pagefaults 0swaps

It is critical to mention the locale you use.
As you see above, I explicitly set LC_ALL=en_US.UTF-8.
Note that when I switch to LC_ALL=C, it halves those times,
although the ~1% win with 2.22 still remains

Would you please compile 2.21 yourself, too? Otherwise, the timing may
be biased by the fact that distribution-provided binaries are often
better optimized than those one gets when building from sources with
the default options. If we can identify a modern system for which
there is anywhere near a 2x performance regression, I would be very
interested to learn more.