From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8429 invoked by alias); 3 Mar 2003 11:16:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 8415 invoked by uid 71); 3 Mar 2003 11:16:01 -0000 Date: Mon, 03 Mar 2003 11:16:00 -0000 Message-ID: <20030303111601.8414.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= Subject: RE: libstdc++/9876: filebuf::sputc more than 10% slower than putc Reply-To: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= X-SW-Source: 2003-03/txt/msg00072.txt.bz2 List-Id: The following reply was made to PR libstdc++/9876; it has been noted by GNATS. From: =?iso-8859-1?Q?P=E9tur_Run=F3lfsson?= To: "Paolo Carlini" Cc: , , , 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