Dinkumware 3.08 std::string performance 
Author Message
 Dinkumware 3.08 std::string performance

I have just switched to Dinkumware 3.08 c++ library and my application
performance has been signification reduced.  I have to note that my
application does not crash anymore, it does at least run now.

Anyway using this test:

   std::string lString1,lString2,lString3;
   long lStartTime = ::GetTickCount();
   for(long lCount = 0; lCount< 10e6; lCount++)
   {
      lString1 = "abcdefghijklmnopqrstuvwxyzabcdefghij";
      lString2 = lString1;
      lString1 = "zyxw";
      lString3 = lString2 + lString1;
   }
   long lStopTime = ::GetTickCount();
It takes 91 seconds to run compiled under the Dinkumware library that
ships with VC++ 6.0 SP5, and it takes 337 seconds to run compiled with
the 3.08 library.  I am using the multithreaded /dll builds in both
cases.  This test was done on a dual processor 800MHz PIII.  A friend
ran the same program on a single process 1400MHz P4 and had the
following times.
        VC6SP5 STL - 31 Second
        STL 3.08 - 36 Seconds

I know the time should be different but the ratio should be about the
same?

Is this because the library is now more thread safe?

Thanks

Rob Kreger



Mon, 16 Aug 2004 03:58:45 GMT  
 Dinkumware 3.08 std::string performance

<snippage>

Quote:

> I know the time should be different but the ratio should be about the
> same?

> Is this because the library is now more thread safe?

The old version used reference counting for strings.  The new version does
not.   Ultimately, yes, this leads to a more thread safe implementation (for
reasons that are complex to go into here...if you search the archives for
this group you'll get an idea).

Basically, each string assignment does a full copy now of the data.  If this
is problematic, you'll need to think of ways to optimize based on the
assumption that the copies are expensive.  (i.e. an external reference
counting mechanism).

By the way, (almost) all of the implementations are moving towards this
approach due to the thread safety problems.



Mon, 16 Aug 2004 04:31:06 GMT  
 Dinkumware 3.08 std::string performance

Quote:

> I have just switched to Dinkumware 3.08 c++ library and my application
> performance has been signification reduced.  I have to note that my
> application does not crash anymore, it does at least run now.

> Anyway using this test:

>    std::string lString1,lString2,lString3;
>    long lStartTime = ::GetTickCount();
>    for(long lCount = 0; lCount< 10e6; lCount++)
>    {
>       lString1 = "abcdefghijklmnopqrstuvwxyzabcdefghij";
>       lString2 = lString1;
>       lString1 = "zyxw";
>       lString3 = lString2 + lString1;
>    }
>    long lStopTime = ::GetTickCount();

> It takes 91 seconds to run compiled under the Dinkumware library that
> ships with VC++ 6.0 SP5, and it takes 337 seconds to run compiled with
> the 3.08 library.  I am using the multithreaded /dll builds in both
> cases.  This test was done on a dual processor 800MHz PIII.  A friend
> ran the same program on a single process 1400MHz P4 and had the
> following times.
> VC6SP5 STL - 31 Second
> STL 3.08 - 36 Seconds

> I know the time should be different but the ratio should be about the
> same?

> Is this because the library is now more thread safe?

You've managed to find the test case that shows the performance difference
at its most extreme. We eliminated reference counting because of the
well known thread-safety problems -- either the code is very slow when
run multithreaded or its full of synchronization surprises. We've replaced
it with what's called the Small String Optimization -- small-enough
strings are stored in the string object proper, while larger ones are
allocated as in the past. See the parameter _BUF_SIZE in <xstring>.
We've set it at 16, based on lots of studies that many strings are
smaller than this size. If your application favors longer strings, you
might consider making _BUF_SIZE larger.

I don't understand why a single-processor system should show less of
a performance difference than a dual-processor system, however.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Mon, 16 Aug 2004 08:51:58 GMT  
 Dinkumware 3.08 std::string performance

Quote:
> The old version used reference counting for strings.  The new version does
> not.   Ultimately, yes, this leads to a more thread safe implementation
(for
> reasons that are complex to go into here...if you search the archives for
> this group you'll get an idea).

Suggestion: For the single-threaded library, why not use reference counted
strings?

Stephen Howe



Tue, 17 Aug 2004 04:06:58 GMT  
 Dinkumware 3.08 std::string performance
In regards to the small string optimization, we use std::wstring almost
exclusively in our application, and it appears that for wchar_t strings,
the struct uses 8 characters (16 / sizeof(wchar_t) on Win32). Do you
think it makes sense to increase that to 32 bytes (16 wide chars) in
light of those studies?

AHG

Quote:


> You've managed to find the test case that shows the performance difference
> at its most extreme. We eliminated reference counting because of the
> well known thread-safety problems -- either the code is very slow when
> run multithreaded or its full of synchronization surprises. We've replaced
> it with what's called the Small String Optimization -- small-enough
> strings are stored in the string object proper, while larger ones are
> allocated as in the past. See the parameter _BUF_SIZE in <xstring>.
> We've set it at 16, based on lots of studies that many strings are
> smaller than this size. If your application favors longer strings, you
> might consider making _BUF_SIZE larger.

> I don't understand why a single-processor system should show less of
> a performance difference than a dual-processor system, however.

> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com



Tue, 17 Aug 2004 04:22:28 GMT  
 Dinkumware 3.08 std::string performance

Quote:

> Suggestion: For the single-threaded library, why not use reference counted
> strings?

We'll consider the possibility, but a lot of code would have to change between
ref-counted and small-string optimized.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Tue, 17 Aug 2004 12:40:59 GMT  
 Dinkumware 3.08 std::string performance

Quote:

> In regards to the small string optimization, we use std::wstring almost
> exclusively in our application, and it appears that for wchar_t strings,
> the struct uses 8 characters (16 / sizeof(wchar_t) on Win32). Do you
> think it makes sense to increase that to 32 bytes (16 wide chars) in
> light of those studies?

Yes, it might. It would make even more sense for us to make it easier
for people to change the value without altering <xstring>. Another good
suggestion, thanks.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



Tue, 17 Aug 2004 12:42:17 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. Visual c++ 6.0 debugger and DInkumware C++ library 3.08

2. ostream copy constructor question while porting to Dinkumware 3.08

3. default new_handler with Dinkumware 3.08?

4. STL Error message filter for MSVC6/Native lib/Dinkumware 3.08: now available

5. convert non std::string to std::string

6. Slightly OT: VC++6, Dikumware 3.08 and Stingray

7. Dinkum 3.08, VC6, and use_facet

8. Dinkum 3.08 and use_facet

9. Dinkum 3.08 and autoexp.dat

10. convert between std::string and std::wstring

11. Warnings for std::vector<std::string>

12. typedef std::vector<std::string> Vector_String

 

 
Powered by phpBB® Forum Software