Uploaded image for project: 'C++ Standard Library'
  1. C++ Standard Library
  2. STDCXX-232

[Solaris] std::string copying is very slow

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.2
    • Component/s: 21. Strings
    • Labels:
      None
    • Environment:

      Solaris

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              sebor Martin Sebor
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: