Re: help needed for libstdc++2.10 reports
On Sun, 9 Dec 2001, Matthias Klose wrote:
> I should not patch libstdc++ myself :-( This is the offending patch,
> introduced to resolve a "severe performance problem" compared to
> gcc-2.95.2. See #92524 and #100571.
> http://bugs.debian.org/92524
> http://bugs.debian.org/100571
>
> --- src-native/libstdc++/sstream~ Tue Dec 5 06:32:17 2000
> +++ src-native/libstdc++/sstream Tue Jun 26 07:11:03 2001
> @@ -106,7 +106,7 @@
> if (c != EOF)
> {
> streamsize old_stream_len = stream_len;
> - stream_len += 1;
> + stream_len += stream_len + 1;
Yeah, I can see how this would cause the problems given in 109073. The
original line above seems to increase the stream_len buffer one char at a
time, as the submitter noted in #92524, but while the new above line would
increase the length faster, if those bytes aren't filled, you'll probably
end up with extra (random) chars at the end of whatever is supposed to be
in the buffer.
I don't see a nicer/speedier way of doing this without going to something
like what libstdc++-v3 does (which uses pointer math and is probably much
faster). See strstream.cc:458 in the libstdc++-v3 sources for an example
of that.
> So the safest thing would be to revert the patch. Could somebody have
> a look for a correct fix? The testcase provided in #109073 and #115978
> fails with this patch.
> http://bugs.debian.org/109073
> http://bugs.debian.org/115978
Reverting is safe, although it won't help the performance woes of the
prior reports. The big question is, is it really helping to rewrite the
code? If you revert, the code will work as expected, albeit slowly in
some cases. If you rewrite it, it may speed it up, but won't get the
needed testing to debug it properly for probably quite some time.
You could also appeal to upstream to make the old code behave and look
more like the new code :-P
C
Reply to: