From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14208 invoked by alias); 18 Apr 2002 04:56:02 -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 14180 invoked by uid 71); 18 Apr 2002 04:56:01 -0000 Date: Wed, 17 Apr 2002 21:56:00 -0000 Message-ID: <20020418045601.14179.qmail@sources.redhat.com> To: jason@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Benjamin Kosnik Subject: Re: libstdc++/4150: catastrophic performance decrease in C++ code Reply-To: Benjamin Kosnik X-SW-Source: 2002-04/txt/msg00912.txt.bz2 List-Id: The following reply was made to PR libstdc++/4150; it has been noted by GNATS. From: Benjamin Kosnik To: Jason Merrill Cc: libstdc++@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/4150: catastrophic performance decrease in C++ code Date: Wed, 17 Apr 2002 21:46:14 -0700 First of all, thanks. I was hoping somebody else would touch this code. > A problem with the current implementation of this is that if we do a > read on an input/output filebuf, we end up writing the contents of the > buffer back out to the file, even if we've never requested a write. > Oops. Hmmm. Please write a testcase that demonstrates this, and add it to 27_io/filebuf_members.cc I know that file is kind of long and unwieldy at this point. I'm trying to have the testsuite actually work and prevent lossage.... I know it's more work for you, but it'll be less work in the long run for all concerned if all regressions are in the testsuite. > In v3, this problem is handled, basically, by contaminating streambuf > with information about filebuf semantics. We need the streambuf > member functions to adjust _M_out_cur with _M_in_cur, so we add a flag > (_M_buf_unified) that says so, and handle the logic in the > _M_*_cur_move functions. Similarly, for the benefit of stringbuf, we > pretend that we can just bump _M_out_end if we run up against it and > we happen to know that there's still room in the buffer. > > It seems unfortunate to me that we need special hacks in streambuf to > support both of the standard derived streambufs. Both seem to be for > optimization; the filebuf hack to allow reading and writing on the > same buffer, and the stringbuf hack to avoid having to call overflow() > through the vtable for each character we want to add to the end of the > string. Am I right? Right. The design is actually for stringbufs. > logauswerter.C times: > synced not synced > 2.96 0:19 0:19 > pre-patch 1:09 0:14 > post-patch 0:26 0:13 > > Interesting that v3 is faster than v2 when not synced with stdio... Yeah. I noticed this with bench++ as well. There was some commentary on this a bit ago, but I cannot place it. The thing that sucks are the narrow/wide stream objects and sync_with_stdio. > I feel like I know my way around streambufs a lot better now. Great. So, how do you like debugging C++ with the current tools? Painful, huh? Does it make you feel psychic when you fix things? ;) Please let me know if you have any special kung-fu to pass on. > Tested i686-pc-linux-gnu, no regressions. Any objections? Mainline and branch have diverged a bit right now. Did you test with branch or mainline? I need to get solaris back in shape on mainline: bsd's, hpux, aix, cygwin are all back in shape now, but solaris is still kind of dicy. I'm going to ask you to hold off, at least on the branch, till I have the libstdc++/4164 patch integrated. Also, you'll need to do the testsuite entry before you can check in. Okay? Does this mean that the FSEEK hacks in config/os/*/bits/os_defines.h can be removed, since this define is no longer used? -benjamin