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: Pétur Runólfsson <peturr02 at ru dot is>
- To: "Paolo Carlini" <pcarlini at unitus dot it>
- 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: Mon, 3 Mar 2003 11:07:44 -0000
- Subject: RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc
> 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! ;)
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.
>
> Are you willing to work on this?
Yup.
Petur