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

["Pétur Runólfsson" <peturr02@ru.is>]

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

From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= <peturr02@ru.is>
To: "Paolo Carlini" <pcarlini@unitus.it>
Cc: <paolo@gcc.gnu.org>,
	<gcc-bugs@gcc.gnu.org>,
	<nobody@gcc.gnu.org>,
	<gcc-gnats@gcc.gnu.org>
Subject: RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc
Date: Mon, 3 Mar 2003 11:07:44 -0000

 > Very Interesting issues... Indeed, putc_unlocked is _much_=20
 > faster (3 x ?)
 >=20
 > However...
 >=20
 > The interesting thing is the following: a series of streambuf::sputc,
 > does _not_ call an underlying C-library putc, but instead,=20
 > upon overflow,
 > an underlying _M_file.xsputn, which means an underlying=20
 > _locked_ fwrite,
 > _not_ an underlying fwrite_unlocked!
 >=20
 > So, I would argue that your comparison was not fair before,=20
 > and it's not
 > fair now! ;)
 
 The locking inside fwrite seems to be totally wasted, since
 filebuf isn't threadsafe at all (for that, [io]stream::sentry
 would need to handle the locking), and also _M_really_overflow
 calls fwrite twice (once with BUFSIZ characters, and then with
 1 character).
 
 > 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.
 >=20
 > Are you willing to work on this?
 
 Yup.
 
 Petur