This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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!
 >>   =20
 >>    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
 Hi Petur.
 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]