incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Closed: (STDCXX-232) [Solaris] std::string copying is very slow
Date Wed, 28 Jun 2006 19:24:30 GMT
     [ http://issues.apache.org/jira/browse/STDCXX-232?page=all ]
     
Martin Sebor closed STDCXX-232:
-------------------------------

    Fix Version: 4.1.2
     Resolution: Fixed

Not a problem with the latest stdcxx as the numbers below indicate:

$ time LD_LIBRARY_PATH=../lib ./t
total time it ran was: 27 seconds.

real    0m27.435s
user    0m27.399s
sys     0m0.025s

$ CC -O -mt t.cpp && time ./a.out   # Sun C++ 5.8 on Solaris 10
total time it ran was: 29 seconds.

real    0m29.721s
user    0m29.601s
sys     0m0.028s

$ CC -O -mt t.cpp -library=stlport4 && time ./a.out   # Sun C++ 5.8 with bundled STLport
4.5
total time it ran was: 93 seconds.

real    1m34.071s
user    1m33.854s
sys     0m0.058s

$ g++ t.cpp -pthreads -O2 && time ./a.out   # gcc 3.4.3 on Solaris 10
total time it ran was: 41 seconds.

real    0m41.217s
user    0m41.161s
sys     0m0.036s

> [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
>      Fix For: 4.1.2

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


Mime
View raw message