This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: Pétur Runólfsson <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
- Date: Fri, 28 Feb 2003 17:43:25 +0100
- Subject: Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028F5535@nike.hir.is>
Pétur Runólfsson wrote:
Yes, filebuf::sputc shall be improved: patches welcome,
or, otherwise, stay tuned!
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=view%20audit-trail&database=gcc&pr=9876