This is the mail archive of the
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: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 28 Feb 2003 16:46:01 -0000
- Subject: Re: libstdc++/9876: filebuf::sputc more than 10% slower than putc
- Reply-to: 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!
>> 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
Very Interesting issues... Indeed, putc_unlocked is _much_ faster (3 x ?)
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?