Return-Path: 
 <stdcxx-dev-return-1616-apmail-incubator-stdcxx-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org
Received: (qmail 97148 invoked from network); 28 Jun 2006 19:24:07 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 28 Jun 2006 19:24:07 -0000
Received: (qmail 97448 invoked by uid 500); 28 Jun 2006 19:24:07 -0000
Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org
Received: (qmail 97406 invoked by uid 500); 28 Jun 2006 19:24:06 -0000
Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:stdcxx-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:stdcxx-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:stdcxx-dev@incubator.apache.org>
List-Id: <stdcxx-dev.incubator.apache.org>
Reply-To: stdcxx-dev@incubator.apache.org
Delivered-To: mailing list stdcxx-dev@incubator.apache.org
Received: (qmail 97395 invoked by uid 99); 28 Jun 2006 19:24:06 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jun 2006 12:24:06 -0700
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jun 2006 12:24:05 -0700
Received: from brutus (localhost [127.0.0.1])
	by brutus.apache.org (Postfix) with ESMTP id D2627410005
	for <stdcxx-dev@incubator.apache.org>; Wed, 28 Jun 2006 19:22:29 +0000 (GMT)
Message-ID: <17523592.1151522549858.JavaMail.jira@brutus>
Date: Wed, 28 Jun 2006 19:22:29 +0000 (GMT+00:00)
From: "Martin Sebor (JIRA)" <jira@apache.org>
To: stdcxx-dev@incubator.apache.org
Subject: [jira] Created: (STDCXX-232) [Solaris] std::string copying is very
 slow
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
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

[Solaris] std::string copying is very slow
------------------------------------------

         Key: STDCXX-232
         URL: http://issues.apache.org/jira/browse/STDCXX-232
     Project: C++ Standard Library
        Type: Improvement

  Components: 21. Strings  
 Environment: Solaris
    Reporter: Martin Sebor


Moved from the Rogue Wave bug tracking database:

****Created By: sebor @ Jan 22, 2001 03:32:29 PM****
Subject: string copying is very slow
Date: Mon, 22 Jan 2001 13:14:43 -0800 (PST)
From: Mukesh Kapoor <Mukesh.Kapoor@eng.sun.com>
To: oemsupport@roguewave.com
CC: Mukesh.Kapoor@eng.sun.com

Bug 4402856:
-----------
This was recently reported by a customer. The following test case takes
about 8 sec with Gnu C++ and about 272 sec with our C++ 5.2 compiler.
In both cases, -O4 was used to compile. Our 5.2 compiler uses stdlib 2.1.1
but I looked at the stdlib 2.2.1 sources and didn't find much difference. 
Do you have any suggestions on how to improve the performance.

test_string.cc
--------------
#include <iostream>
#include <string>
#include <ctime>

using namespace std;

const int kIterations = 10000000;

int main()
{
  string string1("This is a really cool string.");
  string string2("This is likewise quite a nice string.");
  string tempString;

  clock_t startTime = clock();
  int i;

  for (i = 0; i < kIterations; i++)
  { 
    tempString = string2;
    string2 = string1;
    string1 = tempString;
  
    tempString = string2;
    string2 = string1;
    string1 = tempString;

    tempString = string2;
    string2 = string1;
    string1 = tempString;

    tempString = string2;
    string2 = string1;
    string1 = tempString;
  }
  clock_t endTime = clock();

  cout << "total time it ran was: " << (endTime - startTime)/CLOCKS_PER_SEC << " 
seconds." << endl;

  return 0;
}

****Modified By: sebor @ Jan 22, 2001 04:02:16 PM****
Subject: Re: string copying is very slow
Date: Mon, 22 Jan 2001 15:37:09 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
To: Mukesh Kapoor <Mukesh.Kapoor@eng.sun.com>
CC: oemsupport@roguewave.com
References: 1

Mukesh Kapoor wrote:
> 
> Bug 4402856:
> -----------
...

We're looking at performance in string as I write this. The next version should
be comparable if not faster than the competition. 

The only suggestion I have is for them to try to play with ref counting
(diable/enable). Are they using an MT-safe version or not? The mutex can
significantly affect performance. Does SunPro 5.2 expose any atomic instructions
we could use to bypass creating and locking the mutex? I think Krishna had a
small library that he was hoping to make publicly available as part of the
compiler or OS -- any progress there?

Btw., how important is reference counting to you and your customers? We're
considering switching to non-ref counted implementation.

Regards
Martin

PS The QA incident number for this is #24510.

****Modified By: sebor @ Jan 22, 2001 05:18:07 PM****
Subject: Re: string copying is very slow
Date: Mon, 22 Jan 2001 17:16:55 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
To: Mukesh Kapoor <Mukesh.Kapoor@eng.sun.com>
CC: oemsupport@roguewave.com
BCC: Matthew Collins <collins@hpsgns1.sgp.hp.com>
References: 1

Mukesh Kapoor wrote:
> 
> > From: Martin Sebor <sebor@roguewave.com>
> >
> > The only suggestion I have is for them to try to play with ref counting
> > (diable/enable). Are they using an MT-safe version or not? The mutex can
> > significantly affect performance. Does SunPro 5.2 expose any atomic
> instructions
> > we could use to bypass creating and locking the mutex? I think Krishna had a
> > small library that he was hoping to make publicly available as part of the
> > compiler or OS -- any progress there?
> 
> In what way do you mean play with ref counting? There is no macro in stdcomp.h
> that does that. Also, won't this break binary compatibility with the library
> that we ship?  I.e., the .o's built by the customer won't work with the .a
> that we ship.

There's the _RWSTD_ONE_STRING_MUTEX and _RWSTD_NO_STRING_REF_COUNT macros but
there are binary compatibility issues. They can do very little in this regard if
they can't recompile the library. We're looking at providing binary compatible
options for string ref counting in the future.

> 
> In our next release (C++ 5.3, WS6U2) we already use atomic instructions to
> update the ref count of strings for MT applications. This is based on Krishna's
> implementation. The user gets this faster version only if he specifies
> -xarch=v8plus or above (-xarch=v9, etc.). We have to support the v8 architecture
> and atomic instructions are available only on v8plus and above.

Excellent!

> 
> In this particular case, the customer is not using threads so there are no
> calls to mutex locks. The performance problem occurs without threads.

Hmmm, then I can't say why it's so much slower. As I said we're optimizing
string for the next release but the optimization is likely to break BC.

> 
> >
> > Btw., how important is reference counting to you and your customers? We're
> > considering switching to non-ref counted implementation.
> 
> The customers care about improved performance. If the performance improves
> significantly then it should be ok. Will there be any significant increase
> in memory usage for non-ref counted implementation?

That depends on how it's used. If an application that heavily relies on
pass-by-value creates huge strings and is careful about not invoking COW then
yes, there will be significant increase in memory usage. But since it's quite
difficult not to trigger COW I don't suppose that many applications would be
affected.

Martin

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira