This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: libstdc++/4150: catastrophic performance decrease in C++ code
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Thu, 18 Apr 2002 06:58:22 -0500 (CDT)
- Subject: Re: libstdc++/4150: catastrophic performance decrease in C++ code
- References: <wvl7kn8vtvj.fsf@prospero.cambridge.redhat.com>
- Reply-to: rittle at labs dot mot dot com
Jason Merrill <jason@redhat.com> writes:
> The current implementation seems to be trying to allow interleaved reads
> and writes on the same buffer, whereas the libio implementation requires a
> flush when switching modes.
Agreed (that it does work this way without your patch).
> Was this difference a deliberate design decision?
Unknown (since I came into this later).
> I'm a bit skeptical of it's usefulness; how often do people
> really read a few characters, write a few characters, and then read a few
> more characters without an intervening seek?
I agree with Nathan's read of the standard here.
[Skipping analysis that seems right.]
> Anyway, here's a patch to clean up filebuf somewhat. It involves these
> design changes: [...]
> logauswerter.C times:
> synced not synced
> 2.96 0:19 0:19
> pre-patch 1:09 0:14
> post-patch 0:26 0:13
(I applied the patch to mainline while I looked at it; minor tweaking
was required and tested it on my hardware/OS.)
logauswerter.C -O2 times, ./a.out <log:
2.95.2 1:00 0:50
pre-patch-main 1:35 1:35
post-patch-main 1:23 1:05
> Interesting that v3 is faster than v2 when not synced with stdio...
> I feel like I know my way around streambufs a lot better now.
> Tested i686-pc-linux-gnu, no regressions.
Tested i386-unknown-freebsd4.5, no regressions (both 3.1 and mainline).
Hand tested some additional cases. test03 in 27_io/narrow_stream_objects.cc
(must be enabled and run interactively by hand) is now broken on this platform.
But it may be a latent issue since the cin buffer size was always constrained
to 1 on this platform. Can you confirm that this case isn't broken for you
with your patch?
> Any objections?
Only the concern I have is about the remaining failing interactive
test case. Assuming that is solved: If you commit it, then I will
commit the simple patch to remove documentation and pre-port
enablement of _GLIBCPP_AVOID_FSEEK. Thus, finally removing the
conformance hack I installed some time ago.
Regards,
Loren