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

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

>> 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?

> With and without the patch, test03 has the same behavior on linux...

OK.  I have no objections on that point then.

> ...it was disabled because I don't think it ever worked.

No one figured out how to properly test it under the automatic
regression tester.

> Do you have that scott s[ny]der redirection test? I can never remember
> what it is. (Which means it should really be checked in, I guess, even
> though that also has to be run by hand.)

This is one I didn't test.  I will play with it.

For the record, this is the only scott snyder test I know about:

http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00108.html

It is not in the test suite in any form (again, it takes external
shell setup unsupported in dejagnu AFAIK).  Here was my last capture
of the analysis of that test and its history:

"Scott thought that cout.flush() / cerr.flush() calls should
 synchronize IO across low-level file handles.  You did not dispute and
 I do not dispute his claim in terms of user expectation and I agree
 that my patch breaks his ideal situation after manually testing his
 case.  Scott also said that without any explicit ostream::flush()
 calls he did not expect any particular interleaving between distinct
 C++-layer handles that happen to map to a shared low-level file
 handle.  I agree with that as well.  Should we not make the
 infrequently-called ostream::flush() do this expensive (system
 call-wise) operation instead of in the main line of
 _M_really_overflow()?"

Regards,
Loren