From stdcxx-dev-return-965-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org Wed Feb 22 00:00:49 2006 Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 84397 invoked from network); 22 Feb 2006 00:00:49 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 22 Feb 2006 00:00:49 -0000 Received: (qmail 20892 invoked by uid 500); 22 Feb 2006 00:00:49 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 20876 invoked by uid 500); 22 Feb 2006 00:00:49 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 20841 invoked by uid 99); 22 Feb 2006 00:00:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2006 16:00:48 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [12.17.213.84] (HELO bco-exchange.bco.roguewave.com) (12.17.213.84) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Feb 2006 16:00:47 -0800 Received: from [10.70.3.113] (10.70.3.113 [10.70.3.113]) by bco-exchange.bco.roguewave.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id ZGW285KX; Tue, 21 Feb 2006 17:00:05 -0700 Message-ID: <43FBAA9D.7020901@roguewave.com> Date: Tue, 21 Feb 2006 17:04:45 -0700 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: Benchmarking stdcxx References: <43ECE5A3.1070609@roguewave.com> <43EFC2A3.3030608@roguewave.com> <43FA4647.9040506@roguewave.com> <43FA6633.9060801@roguewave.com> <43FA7F19.9090605@roguewave.com> In-Reply-To: <43FA7F19.9090605@roguewave.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Martin Sebor wrote: [...] > I also ran some simple benchmarks: > > latest gcc > stdcxx 4.0.2 > +---------------+-------+-------+ > | default ctor | 1.00 | 1.22 | > | char* ctor | 1.00 | 1.59 | > | string ctor | 1.00 | 1.05 | > | insert char | 1.00 | .96 | > | insert char* | 1.00 | .56 | > | insert string | 1.00 | .53 | > | sputn | 1.00 | .47 | > +---------------+-------+-------+ > > Clearly there is still some room for improvement. I tweaked the > allocation policy used by stringbuf to double the size of the buffer > (rather than growing by a factor of 1.6 or so) but that didn't make > any difference (which should have been expected). > > The last number is particularly puzzling because, AFAICT, xsputn() > (called by sputn) is optimal. I don't see a significant opportunity > for optimization there. Okay, I now see that it's not quite optimal and understand why. Our implementation uses the generic streambuf::xsputn() which copies the string into the buffer one chunk at a time, calling overflow() to process the contents of the buffer each time it runs out of space. This is optimal for filebuf (which flushes the buffer and starts writing from the beginning) but less so for stringbuf which must reallocate the buffer and copy its contents to the new one every time. This can be optimized by allocating the necessary amount of space ahead of time and simply copying the string into it in one shot. With this optimization in place the new numbers are: +---------------+-------+-------+ | default ctor | 1.00 | 1.22 | | char* ctor | 1.00 | 1.58 | | string ctor | 1.00 | 1.06 | | insert char | 1.00 | 1.23 | | insert char* | 1.00 | 1.39 | | insert string | 1.00 | .60 | | sputn | 1.00 | 1.62 | +---------------+-------+-------+ The string inserter still needs to be optimized but everything else is looking much better. Martin