Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc

[Paolo Carlini <pcarlini at unitus dot it>]

The following reply was made to PR libstdc++/9876; it has been noted by GNATS.

From: Paolo Carlini <pcarlini at unitus dot it>
To: =?ISO-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02 at ru dot is>
Cc: paolo at gcc dot gnu dot org,  gcc-bugs at gcc dot gnu dot org,  nobody at gcc dot gnu dot org, 
 gcc-gnats at gcc dot gnu dot org
Subject: Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Fri, 28 Feb 2003 17:43:25 +0100

 P=E9tur Run=F3lfsson wrote:
 
 >>    Yes, filebuf::sputc shall be improved: patches welcome,
 >>    or, otherwise, stay tuned!
 >>   =20
 >>    However, the funny thing of your PR is that, as a matter of
 >>    fact, I *cannot* reproduce the trend neither with mainline
 >>    (which produces better code, indeed) nor with 3.2.2!
 >>
 >
 >Whoops, s/putc/putc_unlocked/ :-P
 >
 >putc calls flockfile/funlockfile for each character,
 >streambuf::sputc does not do so and should be compared against
 >putc_unlocked.
 >
 
 Hi Petur.
 
 Very Interesting issues... Indeed, putc_unlocked is _much_ faster (3 x ?)
 
 However...
 
 The interesting thing is the following: a series of streambuf::sputc,
 does _not_ call an underlying C-library putc, but instead, upon overflow,
 an underlying _M_file.xsputn, which means an underlying _locked_ fwrite,
 _not_ an underlying fwrite_unlocked!
 
 So, I would argue that your comparison was not fair before, and it's not
 fair now! ;)
 
 Needless to say, you are right, and Nathan is right, about the need to
 improve our streambuf::sputc, but we still do _not_ have real numbers
 to use as a point of reference.
 
 Are you willing to work on this?
 
 Paolo.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit-trail&database=3D=
 gcc&pr=3D9876