You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2006/06/28 21:22:29 UTC
[jira] Created: (STDCXX-232) [Solaris] std::string copying is very
slow
[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 <Mu...@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 <se...@roguewave.com>
Organization: Rogue Wave Software, Inc.
To: Mukesh Kapoor <Mu...@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 <se...@roguewave.com>
Organization: Rogue Wave Software, Inc.
To: Mukesh Kapoor <Mu...@eng.sun.com>
CC: oemsupport@roguewave.com
BCC: Matthew Collins <co...@hpsgns1.sgp.hp.com>
References: 1
Mukesh Kapoor wrote:
>
> > From: Martin Sebor <se...@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
[jira] Closed: (STDCXX-232) [Solaris] std::string copying is very
slow
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ 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 <Mu...@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 <se...@roguewave.com>
> Organization: Rogue Wave Software, Inc.
> To: Mukesh Kapoor <Mu...@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 <se...@roguewave.com>
> Organization: Rogue Wave Software, Inc.
> To: Mukesh Kapoor <Mu...@eng.sun.com>
> CC: oemsupport@roguewave.com
> BCC: Matthew Collins <co...@hpsgns1.sgp.hp.com>
> References: 1
> Mukesh Kapoor wrote:
> >
> > > From: Martin Sebor <se...@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