Re: libstdc++/4150: catastrophic performance decrease in C++ code

[Benjamin Kosnik <bkoz@redhat.com>]

The following reply was made to PR libstdc++/4150; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@redhat.com>
To: Jason Merrill <jason@redhat.com>
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