From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71082 invoked by alias); 16 Nov 2017 11:41:57 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 71062 invoked by uid 89); 16 Nov 2017 11:41:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.3 required=5.0 tests=AWL,BAYES_00,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,KB_WAM_FROM_NAME_SINGLEWORD,RDNS_DYNAMIC autolearn=no version=3.3.2 spammy=H*M:info, H*F:D*info X-Spam-User: qpsmtpd, 2 recipients X-HELO: void-ptr.info Received: from pppoe.185.44.68.223.lanport.ru (HELO void-ptr.info) (185.44.68.223) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 16 Nov 2017 11:41:55 +0000 Received: from ptr by void-ptr.info with local (Exim 4.72) (envelope-from ) id 1eFIYL-0006iU-8H; Thu, 16 Nov 2017 14:41:53 +0300 Date: Thu, 16 Nov 2017 11:44:00 -0000 From: Petr Ovtchenkov To: Paolo Carlini Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/4] libstdc++: avoid character accumulation in istreambuf_iterator Message-ID: <20171116144153.24d397b0@void-ptr.info> In-Reply-To: <429dd8c9-a781-3e57-3242-92bd614adc26@oracle.com> References: <04e468027f8bad7858583db836073af1d7c524f1.1510778853.git.ptr@void-ptr.info> <069c0a67-6f8c-67a0-c0bd-a404264d8dc1@oracle.com> <20171116083122.54714b4a@void-ptr.info> <33717f79-e6f2-c7a6-6cfb-bf01efebb7a3@oracle.com> <20171116140319.321231b1@void-ptr.info> <429dd8c9-a781-3e57-3242-92bd614adc26@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01316.txt.bz2 On Thu, 16 Nov 2017 12:29:37 +0100 Paolo Carlini wrote: > Hi, > > On 16/11/2017 12:03, Petr Ovtchenkov wrote: > > On Thu, 16 Nov 2017 10:39:02 +0100 > > Paolo Carlini wrote: > > > >> Hi, > >> > >> On 16/11/2017 06:31, Petr Ovtchenkov wrote: > >>> Is we really worry about frozen sizeof of instantiated template? > >> Yes we do. See https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html > >> under "Prohibited Changes", point 8. > >> > >> Of course removing the buffering has performance implications too - > >> that's why it's there in the first place! > > "buffering" here is a secondary buffering (after streambuf). > > No relation to performance, but place for incoherence with > > state of attached streambuf. > It depends, we may be dealing with an unbuffered stream. For sure at the > time we measured a performance impact in some cases, likewise whoever > implemented it in the first place (not me) otherwise, again, why bothering? This part of code is from SGI, so I suspect that nobody here really measure performance difference between "bufferred" and "non-buffered" implementations. Just because we have only implementation with _M_c in isreambuf_iterator. > > Paolo. > -- - ptr