libstdc++/9876: filebuf::sputc more than 10% slower than putc
Pétur Runólfsson
peturr02@ru.is
Mon Mar 3 11:16:00 GMT 2003
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
More information about the Gcc-prs
mailing list