[Bug libstdc++/21286] [4.0/4.1 Regression] filebuf::xsgetn vs pipes

["ralfixx at gmx dot de" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From ralfixx at gmx dot de  2005-04-30 14:16 -------
Paolo Carlini wrote:
> I'd like to know your opinion, as a user: are you
> noticing worthwhile performance improvements? 
> Would you consider very annoying trying to read again
> (calling clear()), when pipes are used? 

The issue seems already solved, but I'd like to add a comment to this question:
Yes, I would find it very annoying, since my program simply does not know
whether  a file descriptor is connected to a pipe or not.  Note that I have oly
checked for eof() im my program, so the above solution basically means: on
eof(), clear() and try to read again.  How often should I try this?  Etc.

Performance improvement or not, the stream should (must?) give the same results
regardless of the data source IMHO.  Performance can only be second here.

BTW, the program timing is as follows on my machine (reading from local file
system /tmp):

gcc 3.3.3: 
0.01user 0.01system 0:00.08elapsed 31%CPU (0avgtext+0avgdata 0maxresident)k
0.01user 0.00system 0:00.08elapsed 23%CPU (0avgtext+0avgdata 0maxresident)k
0.01user 0.01system 0:00.11elapsed 25%CPU (0avgtext+0avgdata 0maxresident)k
0.01user 0.01system 0:00.08elapsed 27%CPU (0avgtext+0avgdata 0maxresident)k

gcc 4.0.0 (when reading all bytes from the pipe, not with the short reads)
0.00user 0.01system 0:00.04elapsed 38%CPU (0avgtext+0avgdata 0maxresident)k
0.00user 0.01system 0:00.04elapsed 48%CPU (0avgtext+0avgdata 0maxresident)k
0.00user 0.01system 0:00.04elapsed 27%CPU (0avgtext+0avgdata 0maxresident)k
0.00user 0.01system 0:00.04elapsed 35%CPU (0avgtext+0avgdata 0maxresident)k

So yes, there seems to be a performance improvement (1.x CPU, half wall clock time).

Best regards
R'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21286