GNU bug report logs - #18402
Wrong output for single character files without newline

Previous Next

Full log

Message #25 received at 18402 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Jim Meyering <jim <at> meyering.net>
Cc: 18402 <18402 <at> debbugs.gnu.org>
Subject: Re: [bug-diffutils] bug#18402: bug#18402: Wrong output for single
 character files without newline
Date: Thu, 04 Sep 2014 17:34:15 -0700

Jim Meyering wrote:
> I also tried with two copies of the output of "seq 9999999" on a
> tmpfs file system, with the same result: no discernible difference.

There is something weird going on, as I can't reproduce my earlier 
results.  Perhaps I built one version of 'diff' without optimization and 
the other one with it, by accident.  Sorry about sending you down a wild 
goose chase.

I'm still seeing a significant performance improvement due to the 
change, though not as dramatic as what I earlier reported.  Here's the 
benchmark:

$ seq 100000000 >0
$ cp 0 1
$ time ./diff-old 0 1

real    0m2.540s
user    0m1.055s
sys     0m1.464s
$ time ./diff-new 0 1

real    0m1.734s
user    0m0.256s
sys     0m1.463s

where 'diff-old' and 'diff-new' are the old 
(b6e691277288c4e8d53b1d2577137d265008d13e) and current 
(df3af29627a92495a740da13cb8bb0d4fcc1bf84) versions of diffutils, both 
compiled with plain 'configure; make' on the same Fedora 20 x86-64 
platform I mentioned earlier.  This is on an ext4 file system that is 
built atop a mirrored hard-disk subsystem, and the locale is en_US.utf8 
(dunno if any of this matters).

This benchmark is dominated by system CPU time, so the new version is 
only about 45% faster than the old if one looks at real time, but it's 
still clearly a win as the user CPU time about 4x faster.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.